nix-shell no longer works when `argv[0]` is not nix-shell

[nagisa]

Migrated from https://github.com/NixOS/nixpkgs/issues/39307#event-1616934372

Issue description

I have an alias to nix-shell called ns. This alias is passing the argv[0] of the actual alias to the command, which used to work before but doesn’t any longer with the following error

$ strace -e trace=execve ns -p gcc 
execve("/run/current-system/sw/bin/ns", ["ns", "-p", "gcc"], 0x7fff7471c4c0 /* 40 vars */) = 0
execve("/nix/store/ymnw2mphwf1bc33v2vvh7z4vswmhj7lw-nix-2.0/bin/nix-shell", ["ns", "--run", "fish", "-p", "gcc"], 0x7ffe6a0b88b8 /* 40 vars */) = 0
these derivations will be built:
  /nix/store/2ppfqblnfjnswz4gm9qd7mr1qx9i7qg5-shell.drv
building '/nix/store/2ppfqblnfjnswz4gm9qd7mr1qx9i7qg5-shell.drv'...
builder for '/nix/store/2ppfqblnfjnswz4gm9qd7mr1qx9i7qg5-shell.drv' failed to produce output path '/nix/store/m6810cjvq5mkaqr681h345hf07fwa4hf-shell'
error: build of '/nix/store/2ppfqblnfjnswz4gm9qd7mr1qx9i7qg5-shell.drv' failed
+++ exited with 1 +++

Making sure that argv[0] = "nix-shell" is passed makes the build work again. This is a regression from, I believe, nix 2.0 upgrade.

Steps to reproduce

Compile the following program with cc -o /tmp/test and run /tmp/test:

#include<stdlib.h>
#include<unistd.h>
static char *ARGS[1024] = { NULL };
int main(int argc, char **argv) {
    ARGS[0] = argv[0];
    ARGS[1] = "-p";
    ARGS[2] = "gcc";
    ARGS[3] = "--run";
    ARGS[4] = "gcc --version";
    return execv("/run/current-system/sw/bin/nix-shell", ARGS);
}`

Using the actual command name as argv[0] is desirable, because it improves the help messages etc.

[edolstra]

I don't see a way to fix this. It probably only worked in Nix 1.x because nix-shell was a Perl script, so the script name probably was passed to Perl unmolested in argv[1].

[edolstra]

A workaround is to use the old (deprecated, undocumented) --run-env flag, e.g. exec -a fnord nix-shell --run-env -p hello.

[nagisa]

run-env works for me.

On Wed, May 9, 2018, 12:34 Eelco Dolstra notifications@github.com wrote:

A workaround is to use the old --run-env flag, e.g. exec -a fnord nix-shell --run-env -p hello.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/NixOS/nix/issues/2144#issuecomment-387681694, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0guVirUMwfROnkpezey54-IvGcBMks5twrgQgaJpZM4T324T .

[nagisa]

--run-env flag is no longer accepted.

[dtzWill]

If this is a shell alias, I'm surprised argv[0] is changed, so maybe it's something like a wrapper (not to quibble over terminology) either compiled (like the example on the nixpkgs issue leading to this one) or from a scripting language? If so your best bet might be to set argv[0] to nix-shell when executing the process.

Details depend on what's involved, but AFAIK it's something that can be handled by most languages that let you spawn new commands.

Hopefully that's not obnoxiously intrusive into your workflow/alias, which I am curious to learn more about either way :).

Finally a workaround would be to create a new entry point that essentially does exec -a nix-shell /path/to/nix/bin/nix-build although forwarding the args properly is some magic that I look up so as to not worry about getting it wrong.

Presumably it's what is done if you poke into any wrapper created by Nixpkgs :).

Not saying this resolves the issue but might help get things working for you which seems useful too ;).

On Mon, 18 Feb 2019 11:46:10 -0800, Simonas Kazlauskas notifications@github.com wrote:

--run-env flag is no longer accepted.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/NixOS/nix/issues/2144#issuecomment-464855328Non-text part: text/html

[nagisa]

Hopefully that's not obnoxiously intrusive into your workflow/alias, which I am curious to learn more about either way :).

I currently am making sure that argv[0] is set to nix-shell to work around this issue, however, it is desirable to use argv[0] in general, so that when the application outputs an error that contains argv[0] it would be whatever user typed, not whatever the end binary happens to be.

[stale[bot]]

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

[stale[bot]]

I closed this issue due to inactivity. → More info