This would be great for FreeBSD support.

👍 I'm a big zsh user and this would be fantastic to have zsh in nix-shell

Is it work now? How can I enable this?

The problem with non-bash shells is that the shell functions defined by stdenv won't be visible. E.g. running configurePhase in a zsh nix-shell would fail. That's fine if the user is aware of this, but simply changing behaviour based on the value of $SHELL is not a good idea.

I certainly rather have this with that restriction than nothing at all.

Does this have any bearing on #626 and analogous work for other shells?

I, for one, was sorely disappointed to hear that nix was so bash-specific. It's a deal-breaker for me.

@sjfloat I mean nix-shell is not the "core" of nix by any means.

@Ericson2314 No. I maybe should have said, "that nix-shell was so bash-specific". It's just that there are some compelling nix-shell use-cases that grabbed my attention.

Oh, well just running one's own shell within is fine for most practical purposes. I think nix-shell is quite a bit less thought out than most nix tools, but the practical, user-facing ramifications of that are basically just polish, not expressive power.

Oh, I've not given up on nix altogether. I did have a bit of trouble under OS X (which is not my preferred platform, but I am subjected to it at my day-job). I'm going to explore some more under Debian (or maybe NixOS :)

But is it even possible to load ZSH on nix-shell (with custom prompt, for example, for this shell)? I can not found appropriate solution.

Surely, I can use shellHook, run zsh here & use custom rc files (or use nix-shell --run 'zsh --rcs ./.zshrc'), but this solution isn't so flexible (each user may want to have own rc setup)...

BTW it's handy to use separate history file for each environment as well.

@edolstra @gebner are we open to changing the way the environment sees shell functions like configurePhase? For example we can wrap each shell function into it's own executable and add the paths to those in the environment. Similar to how I think rbenv shims work. Thoughts?

What's holding this PR up? It was opened a long time ago, doesn't have any conflict with base, is simple, and is often-requested.

Shouldn't nix use shell configured in binsh as a shell in configurePhase, etc, but user's shell as a shell for nix-shell?

If I interpret @edolstra’s comment correctly, I think the way to move this forward would be to make stdenv’s setup script zsh-compatible and set up some automated test to ensure zsh will still work in the future.

I think there are two quite distinct use cases for nix-shell.

One is as a development tool when you're writing nix packages; getting you into the shell with all the dependencies required and being able to run the various build phases. There it makes sense to say "the standard build setup is implemented in bash, bash is what you get".

But another use case is to drop into ad-hoc views of the software installed on your system, because you want to use that software but don't want it globally installed. Here the availability of configurePhase isn't that big a deal, but being able to use the same shell I normally use is quite important.

I would think that making stdenv's setup simultaneously bash and zsh compatible adds some non-zero ongoing cost (at least having to test all future changes in both), and it only gets you nix-shell compatibility for one additional shell; there are a lot of other reasonable choices for a personal shell.

Perhaps a better option would be to a flag or a separate command or something, to inform the system which use case you're intending? I would be perfectly fine with a variant of nix-shell that used my configured shell but didn't give me access to stdenv functions (and I'd use it far more often than one that forced bash but did give me that access; in fact I mildly prefer not having those extra functions in my environment most of the time). But having to switch my SHELL back and forth to get access to both use-cases would be a pain if I need both modes. (Edit: I just saw that #777 is exactly this suggestion)

(Personally I currently just have something like alias ns='nix-shell --command zsh')

@cumber I use nix-shell mainly to develop things (that aren't necessarily Nix packages). Like a super powered virtualenv. I also make use of the shellHook to do things similar to dotenv practices in other dev environments. It is true that those extra functions are not necessary in this use case, and I would like to use ZSH. However we also have to make sure all of the "packageHooks" still work in ZSH and any other shells that are supported.

I'm not sure about this, but if nix-shell's functions were made to be restricted to posix sh, then it should work for a lot of different shells right? Does the current system make use of bash specific features?

Would something like source <(nix-shell --command env) work? This way you can support other shells with a simple wrapper that injects the environment (just inheriting environment from the shell doing the source might clash with shell's initialisation), I'm sure people on non-POSIX shells would appreciate that (fish comes to mind)

@ktosiek isn't that more or less the same as doing nix-shell --command zsh?

I marked this as stale due to inactivity. → More info

AFAIK still actual.

Would love to have this.

I marked this as stale due to inactivity. → More info

I would hope stalebot wasn't used. But I guess it's too hard to filter based on days since last change in github issues?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/usability-study-session-1/21398/1

When will this be merged if ever?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2022-12-09-nix-team-meeting-minutes-15/23951/1

Any issues with this PR, besides conflicts? I would be glad to fix, feel free to @ me. It looks straightforwards and exceptionally convenient for non-bash users.

Note to folks searching for a workaround, this can be used instead of --command <shell> in one's shell profile:

export NIX_BUILD_SHELL=<shell>

Also, for what it's worth, inheriting $SHELL to have the same behavior as the NIX_BUILD_SHELL environment variable is better than having to use --command=<shell>.

Reasoning: --command=<shell>, with a default installation of nix, will attempt to use the nixpkgs provided shell, as opposed to the user's system shell (current behavior of NIX_BUILD_SHELL). This means that when using --command=<shell> (e.g. without --pure mode), the user can loose all the goodies they have in their shell profile (i.e. bash will ship with the default nixpkgs bash profile).

For me, setting NIX_BUILD_SHELL to zsh and then running nix-shell -p atool fails with bash: no such option: rcfile.

Discussed in Nix team meeting on 2023-01-09:

There are two use cases:

1. establishing a shell environment
2. debugging a derivation

The first should be shell agnostic, the other one must not be. This distinction is made in the new CLI, but not in the old one. The PR does not address the distinction and is therefore not correct, which is why we close it now.

We acknowledge that it's a tricky problem to address for nix-shell without lots of code churn, which @edolstra expressed aversion against. The team agrees that we want to support the use case in principle, but we still have to converge on a clear strategy and have to balance the effort with other topics of interest.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-01-09-nix-team-meeting-minutes-22/24577/1

Why has this been closed? Isn't this still an issue?

We provided rationale in the closing comment. I find it still holds.

In my opinion, the new CLI does not address the issue well. I was recently exploring my hunch that both the package management and the stdenv-based build-debugging functionality should actually live in Nixpkgs, and some preliminary sketches show it can be done fairly easily, but it would need more systematic support from Nixpkgs facilities to take off. But someone needs to put in the work and everyone I know is busy solving other problems that are just as valid.

Here's a little update since this thread seems to have quite some traffic. @roberth is slowly working towards implementing said Nixpkgs facilities in NixOS/nixpkgs#324789, and we're discussing the design on and off. Here's my high-level summary of the next couple of steps: #4702 (comment)