Set custom argv0 for lix custom sub-commands #1225

New issue

Open

opened 2026-06-03 15:21:43 +00:00 by blokyk · 2 comments

blokyk commented

2026-06-03 15:21:43 +00:00

Member

The lix-custom-sub-commands experimental feature is very useful, but its actual use is somewhat limited by the fact that the executed program has no way of knowing if it's being launched as a regular program or as a lix sub-command. For example, I'd have like to allow nix-debug to have a nix3-style interface when called as lix debug, but there's no way of knowing if a user manually called it as lix-debug (which would have a nix2 interface) or lix debug (with a nix3 interface).

Describe the solution you'd like

Set sub-command's argv[0] to lix $cmd (e.g. lix debug).

Describe alternatives you've considered

None.

Additional context

This is a very minimal change, but I thought I'd get validation about it beforehand :)

## Is your feature request related to a problem? Please describe. The `lix-custom-sub-commands` experimental feature is very useful, but its actual use is somewhat limited by the fact that the executed program has no way of knowing if it's being launched as a regular program or as a lix sub-command. For example, I'd have like to allow [`nix-debug`](https://github.com/blokyk/nix-debug) to have a nix3-style interface when called as `lix debug`, but there's no way of knowing if a user manually called it as `lix-debug` (which would have a nix2 interface) or `lix debug` (with a nix3 interface). ## Describe the solution you'd like Set sub-command's `argv[0]` to `lix $cmd` (e.g. `lix debug`). ## Describe alternatives you've considered None. ## Additional context This is a very minimal change, but I thought I'd get validation about it beforehand :)

blokyk added the

Downstream Dependents

Area/cli

E/easy

labels

2026-06-03 15:21:43 +00:00

pennae commented

2026-06-03 16:23:42 +00:00

Owner

the nix2 cli is completely dead end in every possible way. new commands should be encouraged to not repeat the same mistakes and provide a uniform interface for all things instead? do you have any command in mind for which it makes any sense for it to change its interface depending on how it was called?

the nix2 cli is completely dead end in every possible way. new commands should be encouraged to *not* repeat the same mistakes and provide a uniform interface for all things instead? do you have any command in mind for which it makes any sense for it to change its interface depending on how it was called?

blokyk commented

2026-06-03 16:35:58 +00:00

Author

Member

the nix-debug example i linked is supposed to be a small, drop-in wrapper around nix-build, and i'd like to also make it possible to use it as a wrapper around the nix3 nix build, without having to generate two separate executables. currently, i instead have to translate any nix3 build invocation to nix2-style, and if i switched nix-debug to always use nix build under-the-hood, i would then have to always translate nix2 invocations to nix3, which is frustrating for a supposed "drop-in replacement".

in addition, aliasing the same program but with different name/argv0 is a pretty common practice, especially for wrappers and small utilities, which i expect quite a few lix sub-commands might be.

the [`nix-debug`](https://github.com/blokyk/nix-debug) example i linked is supposed to be a small, drop-in wrapper around `nix-build`, and i'd like to also make it possible to use it as a wrapper around the nix3 `nix build`, without having to generate two separate executables. currently, i instead have to translate any nix3 build invocation to nix2-style, and if i switched `nix-debug` to always use `nix build` under-the-hood, i would then have to always translate nix2 invocations to nix3, which is frustrating for a supposed "drop-in replacement". in addition, aliasing the same program but with different name/argv0 is a pretty common practice, especially for wrappers and small utilities, which i expect quite a few lix sub-commands might be.