fnm exec usage text is wrong

[alexeyten]

fnm exec without options shows following text:

 $ fnm exec
error: The following required arguments were not provided:
    <binary>

USAGE:
    fnm exec <binary> --fnm-dir <base-dir> --log-level <log-level> --node-dist-mirror <node-dist-mirror>

For more information try --help

The USAGE text is wrong.
fnm exec --help shows right USAGE clause.

/ $ fnm exec --help
fnm-exec 1.22.9
Run a command within fnm context

Example: -------- fnm exec --using=v12.0.0 -- node --version => v12.0.0

USAGE:
    fnm exec [OPTIONS] <binary> [arguments]...

FLAGS:
    -h, --help
            Prints help information

    -V, --version
            Prints version information


OPTIONS:
        --fnm-dir <base-dir>
            The root directory of fnm installations [env: FNM_DIR=/home/lynn/.fnm]

        --log-level <log-level>
            The log level of fnm commands [env: FNM_LOGLEVEL=info]  [default: info]

        --node-dist-mirror <node-dist-mirror>
            https://nodejs.org/dist/ mirror [env: FNM_NODE_DIST_MIRROR=https://nodejs.org/dist]  [default:
            https://nodejs.org/dist]
        --using <version>



ARGS:
    <binary>


    <arguments>...

[Schniz]

I'm sorry but how this is wrong? Isn't it just more explicit? The former is auto generated by clap (the "wrong" one) and the latter is hand written as a documentation.

[alexeyten]

Well, I guess it just not very familiar format for me.
I'm used to format like in handwritten help where optional arguments are in brackets and positional parameters are listed after named ones.

Also, I found it quite annoying that fnm tries to consume all arguments, I mean that fnm exec --using 14 node -v fails with error and I have to write fnm exec --using 14 -- node -v

So techically usage string should be fnm exec [options] [--] command [command-options] where [--] becames mandatory if command options starts with -.

[ljharb]

That's how every program works - -- to tell the program to stop consuming arguments is a universal unixism.

[alexeyten]

My top used programs stops consuming named arguments after positional

exec node -p process.version
echo process.version | xargs node -p
nvm exec 12 node -p process.version

In all examples above -p is node's argument because it's placed after command. And neither one of them tries to consume -p for itself.

I'm trying to say, that it's more convenient to stop parsing arguments after first positional argument, especially for a program that runs other programs with their own arguments.

[alexeyten]

I guess clap could do this using https://docs.rs/clap/2.32.0/clap/enum.AppSettings.html#variant.TrailingVarArg

[ljharb]

None of those are being passed double-dashed options.

[alexeyten]

None of those are being passed double-dashed options.

That’s the point. They do not require double dash while fnm requires it

[ljharb]

Because fnm has double-dashed options.

[Schniz]

I think a better example would be npm test. If you use jest, and want to run watch mode: npm test -- --watch

That being said, if we can try making this easier and nicer, let's do it. It's a cosmetic change but I will see if I can make it work when I have free time 😃

[alexeyten]

Yep, and I don’t like npm for this behavior. E.g. yarn allows you to write simply yarn test --watch

[Schniz]

Let's see if we can use what you suggested. I agree that it would be best.

By the way I always put the double dash on yarn and it constantly mentions that I can avoid doing that. The funny thing is that on npm I constantly do the opposite. Don't know why!

[ljharb]

If you don't use the explicit --, then you can never add a new double-dash argument without it being a breaking change, which is indeed a problem yarn already has.

[Schniz]

If you don't use the explicit --, then you can never add a new double-dash argument without it being a breaking change

Maybe, if we can skip the argument parsing after the first positional argument, we can pull off something like:

$ fnm exec --using=12 node -v
           ^^^^^^^^^^      ^^
             fnm argument    node argument 
$ fnm exec -- node -v # still works

Not sure that it is possible, but we can check.

This way, we can introduce arguments as much as we want, and when you provide the command name, it's not our problem anyway. Is it still an issue this way? 🤔

[alexeyten]

If you don't use the explicit --, then you can never add a new double-dash argument without it being a breaking change, which is indeed a problem yarn already has.

You can if you declare that everything after first positional argument is never an option for fnm itself or fnm’s subcommand. Yes, introducing this would be a breaking change, but after that there is no problem to add new options.

And actually I don’t think that anybody ever really used something like this fnm exec node --using v12 -- -v

[ljharb]

@alexeyten unix conventions mean that there's a universal expectation that non-positional args (--foo=bar or -f x pairs) can be provided in any order, including at the end, after positional args.

[alexeyten]

Unix convention is that after double dash all args are positional even if they starts with dash. But it doesn’t mean (or require) to accept named arguments anywhere.

xargs is perfectly unix and doesn’t require double dash.

Another example would be watch. From man page: watch -d ls -l. It doesn’t treat -l as option for watch.

[ljharb]

I’m not familiar with watch in posix, but xargs is a good point.