3 ms·

> wasmer run wasmer/ffmpeg -- -i - -f wav - > audio.wav rather off-topic, but i've noticed quite a few "modern" cli apps do the "--" thing and make it mandator

by 5- 3y ago

> wasmer run wasmer/ffmpeg -- -i - -f wav - > audio.wav rather off-topic, but i've noticed quite a few "modern" cli apps do the "--" thing and make it mandatory; am i alone in finding it weird that flag parsing does not automatically stop after the positional argument for a program that expects to accept a command line? e.g. it's sudo -E env -v not sudo -E -- env -v or sudo -E env -- -v (sudo stops parsing its own flags after 'env', the positional argument).

jchw 3y ago
I believe this originates from GNU argument syntax and is commonly implemented by software supporting GNU-style long options. Terminating after the first argument IIRC is what software implementing BSD style argument parsing usually does. OTOH though, I am sure there is software that implements hybrids of both approaches. I don't think any approach is particularly "weird" really, both of them make perfect sense in isolation. edit: relevant GNU docs https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html https://www.gnu.org/software/libc/manual/html_node/Argument-...
semiquaver 3y ago
Maybe more apps should do like git and make `--end-of-options` the official long form of `--` https://git-scm.com/docs/gitcli https://git-scm.com/docs/gitcli
btown 3y ago
AFAIK it's all about trying to be POSIX-but-not-quite. Via the POSIX spec https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... : > The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character. > All options should precede operands on the command line. > If an argument can be identified according to Guidelines 3 through 10 as an option, or as a group of options without option-arguments behind one '-' delimiter, then it should be treated as such. I think that the rule "all options should precede operands" has been broken so much in practice (particularly since any subcommand must break it) that it may as well not be a rule. And if it's not a rule, then the only way to unambiguously distinguish options from operands-that-start-with-a-dash-but-should-be-passed-verbatim-as-operands... is to require a double-dash.
Groxx 3y ago
If they accept only one positional argument, and do not allow flags after it, yeah that definitely seems weird. Many of these are flag-position-agnostic though, and for that the -- is a very long-time standard pattern for either "end of this command, forward the rest to the wrapped command" or a list of files (to make a file named --help unambiguous). Many. Definitely not all. CLI interfaces are even more varied than GUIs in many ways.

by 5- 3y ago

jchw 3y ago

I believe this originates from GNU argument syntax and is commonly implemented by software supporting GNU-style long options. Terminating after the first argument IIRC is what software implementing BSD style argument parsing usually does. OTOH though, I am sure there is software that implements hybrids of both approaches. I don't think any approach is particularly "weird" really, both of them make perfect sense in isolation. edit: relevant GNU docs https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html https://www.gnu.org/software/libc/manual/html_node/Argument-...

semiquaver 3y ago

Maybe more apps should do like git and make `--end-of-options` the official long form of `--` https://git-scm.com/docs/gitcli https://git-scm.com/docs/gitcli

btown 3y ago

AFAIK it's all about trying to be POSIX-but-not-quite. Via the POSIX spec https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... : > The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character. > All options should precede operands on the command line. > If an argument can be identified according to Guidelines 3 through 10 as an option, or as a group of options without option-arguments behind one '-' delimiter, then it should be treated as such. I think that the rule "all options should precede operands" has been broken so much in practice (particularly since any subcommand must break it) that it may as well not be a rule. And if it's not a rule, then the only way to unambiguously distinguish options from operands-that-start-with-a-dash-but-should-be-passed-verbatim-as-operands... is to require a double-dash.

Groxx 3y ago

If they accept only one positional argument, and do not allow flags after it, yeah that definitely seems weird. Many of these are flag-position-agnostic though, and for that the -- is a very long-time standard pattern for either "end of this command, forward the rest to the wrapped command" or a list of files (to make a file named --help unambiguous). Many. Definitely not all. CLI interfaces are even more varied than GUIs in many ways.