New style `nix shell` shebang tries to use default package / doesn't recognize script

[roberth]

Describe the bug

I wrote a new-cli shebang script for use in Nixpkgs, but it fails.

pkgs/development/haskell-modules/hotfixes/update.sh

#!/usr/bin/env nix
#! nix shell ../../../..#cabal2nix

fails with

$ nix shell nix/2.20-maintenance
$ ./update.sh
path '/home/user/src/nixpkgs/pkgs/development/haskell-modules/hotfixes/update.sh' does not contain a 'flake.nix', searching up
warning: Git tree '/home/user/h/nixpkgs' is dirty
warning: Git tree '/home/user/h/nixpkgs' is dirty
error: flake 'git+file:///home/user/h/nixpkgs' does not provide attribute 'packages.x86_64-linux.default' or 'defaultPackage.x86_64-linux'

$ nix --version
nix (Nix) 2.20.5

or on master (2.21pre)

$ ./update.sh
error: path '/home/user/h/nixpkgs/pkgs/development/haskell-modules/hotfixes/update.sh' is not a flake (because it's not a directory)

It appears that nix does not recognize that it's a shebang interpreter, or fails to recognize which argument is supposed to be the script.

Steps To Reproduce

1. Apply the above in nixpkgs repo

Expected behavior

nix recognizes that one of the arguments is the script.

nix-env --version output

2.20 or 2.21pre, as above.

Additional context

Feature authors: @tomberek @roberth

Priorities

Add :+1: to issues you find important.

[roberth]

Adding a line like

#! nix -i ../../../..#bash

does not help (except to make it slower)

[tomberek]

We don't detect or manage the script name argument or do anything smarter with it than appending it. The expected way to do your example is:

#!/usr/bin/env nix
#! nix shell .#cabal2nix .#bash -c bash
...

The update script invalidates nixpkgs itself, which can get annoying. An approach to fix that can be like this, depending on what behavior you want.

#!/usr/bin/env nix
#! nix shell ./../../../..?ref=HEAD#cabal2nix ./../../../..?ref=HEAD#bash -c bash
echo starting

[roberth]

I forgot. I think it'd be good to highlight this mechanism in the manual.

[dmadisetti]

Not positive, but I think I faced a regression re this feature. A script that was working- now no longer does. It might be work getting in some unit tests too.

---

Edit I may have just had an older version between machines somehow- either way it would be nice to have that sanity check