#! nix-shell -i bash use bash from shell.nix

[Radvendii]

When nix-shell is non-interactive, we don't need to make sure we launch
an interactive bash, and it's more important to get the pinned bash

I'm a little worried this will break NixOS/nixpkgs#27493

@domenkozar (from that nixpkgs issue)

@edolstra @thufschmitt (discussed the problem & solution earlier)

TODO:

• communicate better what is going on to the user. if they unset NIX_PATH, they still get a scary error message despite it not really being an issue in shebang mode.

[Radvendii]

Oh. As I feared there's an error on Mac. Does anyone who uses mac have an insight into what's going on?

error is here https://github.com/NixOS/nix/runs/6275913110?check_suite_focus=true#step:6:1635

[Radvendii]

never mind? error seems to have magically disappeared.

[thufschmitt]

never mind? error seems to have magically disappeared.

I’ve restarted the CI ;)

[nixos-discourse]

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

https://discourse.nixos.org/t/tweag-nix-dev-update-30/19112/1

[thufschmitt]

Sorry for the delay. Looks good, I’d just like to see a little test showing the various combinations of bash-es that can happen if that’s not too tricky to do (maybe creating different symlinks to the bash available in the test sandbox, and using $BASH to know which one was used)

[Radvendii]

Right now $BASH and $SHELL are still set to the same value they were before. This was a while ago, so I don't remember our reasoning exactly. Was it deliberate that we left the SHELL= and BASH= lines in?

It would be nice if we could go further and remove the error message (and the whole code-path that leads up to it) in the non-interactive case:

error: file 'nixpkgs' was not found in the Nix search path (add it using $NIX_PATH or -I)

       at «string»:1:9:

            1| (import <nixpkgs> {}).bashInteractive
             |         ^
will use bash from your environment

Since it's not really an error, and we're not using bash from the environment. I am wary though because this code is reused by a bunch of different commands.

I will add tests, and then maybe we should merge this PR as is, and change other things, like the error message, separately?

[domenkozar]

+1 for removing that error message, I set NIX_PATH to be empty on all my machines/environments and it's annoying to see that error pop up.

[fricklerhandwerk]

Triaged in the Nix team meeting 2023-03-17:

We'll wait for tests to be added. @Radvendii do you still have capacity to pursue this?

[nixos-discourse]

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

https://discourse.nixos.org/t/2023-03-17-nix-team-meeting-minutes-41/26614/1

[Radvendii]

So I stumbled across this again 2 years later and finally sat down to tackle it. I realised I'd gotten a couple things wrong.

1. What I thought had to do with interactive/non-interactive really had to do with whether we're in a shebang. If you run nix shell --run "<command>", it might be relevant which bash is running that <command>. If you #!nix-shell -i ruby, it doesn't really matter which bash is executing exec ruby.

2. It still doesn't sit right to me that nix-shell --run "<command>" won't use the bash provided by your shell.nix. I don't think there's a great way to solve this though. We just don't have access to it at the right time.

3. The whole PATH=" + shellEscape(dirOf(*shell)) + ":$PATH" thing going on has nothing to do with anything else, and I'm starting to think it should just go away entirely.

   What it does is set it up so that if you run bash from inside a nix-shell, it will get you the same bash that you were already in. I'm guessing this is in place so you get bashInteractive rather than some non-interactive bash provided by stdenv.mkDerivation, but I would argue that's an issue with mkShell, which should provide an interactive bash by default.