Decorators should allow a `--` separator

[faho]

Noticed in #9940:

If you want to decorate something with command to only call commands, you can't use a -- to avoid it being called as e.g. command -q:

command -- less

should call less, instead it brings up the help for the command builtin.

Same goes for time, and I have no idea what builtin -- -q does (it returns 0?).

For variables this already kinda works because of how we parse what - set -l foo -q grep; command $foo complains that it can't find the command -q.

But regardless, it feels like -- is the intuitive safeguard and I think it should be added.

[mqudsi]

I don't understand why this would be needed; I would say the bug is that build -- -q isn't a syntax error or execution error is the real issue and the same with command -- less bringing up the help for builtin. I would say both of these should just say -- not found or whatever in all cases, not just when used with variable substitution and that would resolve your issue with them?

I guess an executable could be located at ./-a but that seems extremely unlikely and in that case, the command ./-a syntax can be used instead of the command -a syntax anyway. That option wouldn't work if an executable called -a is in $PATH but that just seems wrong on so many levels. I guess we totally can add -- support to handle that, but I think the other quirks in how non-existent payloads to command are handled should be fixed first in all cases, whether or not -- separator support is added, and I would hope that -- never makes an appearance in any of the official documentation or examples and is just there for the weird cases where someone runs into the $PATH issue.

More than anything, I just feel like since command or function is a decorator, it is intended to be tacked on to the name of the head and influences how the parser handles the payload, but it is not conceptually the same as executing command and then passing it the argv that could be misinterpreted as something else - the handling happens within fish, the parser is aware of it at the core, it's part of the core fish syntax, etc. and it is a decorator in the ast, not something that is executed generically and needs to decide at runtime what behavior should be taken.

[faho]

not just when used with variable substitution and that would resolve your issue with them?

No. The problem is this would be used with complete, so the variable substitution would happen before the script. Example:

# ensure $foo is completed *as a command* 
# (this would require `command`'s completions to be fixed)
complete --do-complete="command -- $foo"

In this case I want to avoid $foo being interpreted as an option.

I feel like -- is the obvious choice, because it is already used all over the place. I feel that's the consistent solution.

I guess an executable could be located at ./-a but that seems extremely unlikely and in that case

It could also be at /usr/bin/-a

I just feel like since command or function is a decorator,

It's a decorator and a builtin.

to command are handled should be fixed first in all cases, whether or not -- separator support is added

We can do two things.