Change:
<ins> commit 0ec07a7018bd69513b0bca6e2f22dbf8575a5b5e Author: Jakob Gillich <jakob@gillich.me> Date:   Fri Dec 25 01:59:29 2015 +0100 load /etc/fish/config.fish if it exists diff --git a/etc/config.fish b/etc/config.fish index 0683f40..33f4da7 100644 --- a/etc/config.fish +++ b/etc/config.fish @@ -37,3 +37,6 @@ if status --is-login end end +if test -f /etc/fish/config.fish +  source /etc/fish/config.fish +end </ins>

Discussion:
This is a feature request. May you please make shell easily configurable as a default shell. With , for example, I can simply enable it like so and set . cc
I'm not sure that actually closes this. See
How not? He only asked for being able to put fish in current-system/sw so that he could use it as shell like it's done with zsh. With the PR merged he can perfectly do so.
Setting the default shell to fish with the new module would result in a shell that doesn't inherit any environment from , as bash and zsh do.
It's really so incompatible to not being able to set a couple of variables? In which case I can revert.
And even it if it were compatible, the module doesn't even correctly set up an initialization file from which to source .
Impressive. Reverting, thanks.
The syntax for fish is different, so instead of using , you use . I've been poking around and will try and come up with a reasonable fish script to set up the environment.
Could we get away with a wrapper that sets up the environment and then invokes fish?
For anyone else who gets here from Google, I rewrote a version of in as a stopgap.
do you think this can this be integrated to nixpkgs to provide a somewhat seamless experience for those who want to use fish as their default shell?
I'll look into how gets written and such after work today. I wouldn't expect it to be too labor-intensive.
FWIW trying to set fish as the default shell (though it works when manually running) leads to all sorts of trouble: !
One way to do this is with 'fenv', a fish function defined in the plugin-foreign-env package for Oh My Fish: The fenv function takes a bash command or a path to a bash script, runs it under bash, and then modifies the fish environment appropriately to match any environment variables that were set in the bash environment. Fish also automatically escapes the output of subcommands in the appropriate way, so if we want to use the output of a command, as we would with ssh-agent, for example, without modifying anything to get fish code, we can do or or ssh-agent`` and so on. I think leveraging this function would be a good idea, but what's the best way to go about it?

Should we arrange things so that " = true;" also installs oh-my-fish as well as the plugin for omf in a nixy way? Should we rip out the code from the package? Or maybe, should we just write a nix expression that installs the files for the functions, ripping them directly from git but arranging them in a different location (maybe globally)? Edit: oh-my-fish also has a plugin which implements a function called 'export' that acts like bash's export, so you can just make those export calls and all is well.
Using the function would make it accessible to the user, which she may not want. Plus, if the script one day uses a bash-specific feature, it would raise an error difficult to pin down. IMHO, we should just replicate fenv as a compatibility hook.
Do you have any preference as to how it's done? I'm willing to do it, but idk what I'm doing, really. If you want to gesture in some direction I'd be happy to iterate through a few attempts. On Sun, Dec 6, 2015, 08:11 gpyh wrote:
I'd love to see this fixed, but I'm kinda in the same boat, don't really know how to approach this.
Would appreciate some feedback for the above PR.
Does it work in your system? As I instected the viability some time ago, I found some nixpkgs modules explicitly build array environment variables by concatenating with s, I think does it that way. afaik automatically converts only some few explicit envvars to fish-arrays, e.g. . I suspect those explicit string concatenations need to be abstracted for POSIX-like shells and fish-like shells first.
Of course it works on my system. I've been using it for the last two weeks without any issues (other than . but that was an issue in the package). Just look at the source, it completely bypasses any compatibility issues by importing the environment using fish-foreign-env. Making NixOS fish-compatible is just not possible because we have things like :
That’s nice! I will try to use it.
Thanks for taking care of this, . I'm glad to see this closed. :-)
Can anyone who got this working update the wiki? Currently says Is this still true?

What do I do in my config file if I want to use fish as my shell?
Never mind, I figured it out and I will update the wiki myself :+1:
Just saw this: Anyway the answer is: Easy!
It might make sense to document changing the default shell in the nixos manual, with examples for fish & zsh. Do you want to do that?