Proposal: simpler `nix run` syntax

Recent concerns about the mixing of the new CLI and flakes notwithstanding, the new CLI can be seriously awesome(ly compact) if you buy into it:

$ nix run nixpkgs#cowsay moo

However, my first attempt at adding flags to the command often fails:

$ nix run nixpkgs#cowsay -t moo
error: unrecognised flag '-t'
Try 'nix --help' for more information.

The correct solution is to separate Nix and nested command arguments by --. This makes sense in that Nix flags are order-independent in general, which this separation preserves. However, I’d like to argue that in the case of nix run, convenience should win over consistency with other commands so as to interpret all flags given after the installable as non-Nix flags. It would be extremely convenient, and consistent in a different way, if I could run any cmdline of a program in Nixpkgs by prefixing it with nix run nixpkgs# irrespective of the cmdline flags involved. Furthermore, I can’t think of any reason to ever specify Nix flags after the installable except to confuse other people.

What do y’all think?

3 Likes

Well, I would argue for keeping the current syntax.
I’ve seen the -- <program args> convention in other places, stack exec and npm run-script for example, so a lot of programmers should be familiar with it.

In this situation consistency wins for me, as I believe this change will replace one unpleasant situation (forgetting -- before program arguments) with another one, where legit parameters to nix become errors, e.g. nix run nixpkgs#fd --impure would result in error.

I think the proposed behaviour could be accomplished with a shell alias for users who prefer it, but for me personally remembering to put double dashes is not a big deal anyway.

BTW, it looks like double dash is much more generic than I have thought. From SO:

More precisely, a double dash ( -- ) is used in most Bash built-in commands and many other commands to signify the end of command options, after which only positional arguments are accepted.

3 Likes