5 ms·

This seems to be primarily an argument that "CLIs should support GNU-style double-dash options". I agree with that argument, and in most cases it's easy to add

This seems to be primarily an argument that "CLIs should support GNU-style double-dash options". I agree with that argument, and in most cases it's easy to add support for them. Most option-processing systems support double-dash (long option names), and I find them much easier to explain later. The problem is that at least historically many of the BSD developers, and thus the POSIX standards community, strongly resisted standardizing support for double-dash. So while utilities allowed* to have long option names, the POSIX standard doesn't directly support them and doesn't standardize them. That means that if you want to write portable invocations of common tools, the only way that always works are the short (single-letter) names. It may be time to revisit this decision. If the *BSD developers (and so on) are now willing to accept long names, and the POSIX standard is finally modified to support it, that would eliminate at least one roadblock to actually using them.

vimax 7y ago
Every time I wind up doing > java -v > java --version > java -version
- lerey 7y ago
  Don't forget -V (since some applications use -v for verbose)
  - vimax 7y ago
    This is java, it would be -D-XX:VerboseRuntime=true
    - needusername 7y ago
      -XX is for implementation specific VM flags an generally uses + or - -D is for system property and uses key value so it would either be -XX:+VerboseRuntime or -Djdk.runtime.verbose=true
- Jenz 7y ago
  I laughed a lot at this one
- deleted 7y ago
  [deleted]
- h1d 7y ago
  And then some tools use a sub command instead of just being the obvious '-v' but 'version'.
chubot 7y ago
I think that's a good idea, but even if BSD developers accept them and POSIX changes, we'll still have deployed systems for decades that support only short options. This situation reminds me of the dictatorship of the minority: https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15 https://medium.com/incerto/the-most-intolerant-wins-the-dict... I think a more deployable solution is to write shell function wrappers for all POSIX utils that support GNU-style options. I just filed this as an issue for Oil: https://github.com/oilshell/oil/issues/464 https://github.com/oilshell/oil/issues/464 Note that I also plan to provide long options for all shell builtins, mentioned here: https://news.ycombinator.com/item?id=20724924 https://news.ycombinator.com/item?id=20724924 I'm looking for feedback on Oil from experienced shell users! It takes 30-60 seconds to build and install. https://www.oilshell.org/release/0.7.pre3/ https://www.oilshell.org/release/0.7.pre3/ ----- edit: As mentioned on the issue, busybox and toybox (Android) are probably even less likely to change than POSIX/BSDs. So I do think the solution realistically belongs in the shell.
- big_chungus 7y ago
  Busybox has good reason not to change. It's focused on being lightweight and embeddable, not being user-friendly. It would have to catch both types of flags to maintain compatibility, and parsing for long flags is definitely more complex. Coreutils are different, but busybox is fine with short flags. By the way, oil does look interesting. One key issue is you really need to move to python 3 asap. 4 months and change before it's no longer supported. Plus, people want fancy unicode stuff in shells these days, and that's much easier in python3. Out of curiosity, do you think python vs c will have a major impact on performance? On the other hand, I figure stricter semantics means more room for optimization and slow-down on corner cases. Are there any performance numbers I can look at?
  - chubot 7y ago
    Yes, I'm suggesting that busybox can be kept the same, and the parsing can happen in the shell. I get a lot of comments like yours about Python, but they aren't accurate. This FAQ only helps sometimes, but in case it does: http://www.oilshell.org/blog/2018/03/04.html#faq http://www.oilshell.org/blog/2018/03/04.html#faq tl;dr You're mistaken about Unicode; forking in open source is sometimes a feature, not a bug. Also: http://www.oilshell.org/blog/2019/06/17.html#toc_1 http://www.oilshell.org/blog/2019/06/17.html#toc_1
big_chungus 7y ago
In no small part this is because parsing long opts can be significantly more complicated than short ones. It is by contrast very easy to parse short, single-letter flags. Not saying it's not worth doing, but there is a reason this has not been standardized.
- dwheeler 7y ago
  Parsing long opts is trivial; just determine if the string exactly matches. E.g., "--version" only matches "--version". Short opts is what takes slightly more effort, because you have to accept both "-ld" and "-l -d". We already handle the "hard" case, we just need to support the easy case.
Jenz 7y ago
I cannot imagine how having both long and short options flags can not be portable. Care to enlighten me?
h1d 7y ago
The posix decision is quite dumb. You can't possibly read scripts well with bunch of single letter options. Codes are supposed to be readable.

vimax 7y ago

Every time I wind up doing > java -v > java --version > java -version

lerey 7y ago
Don't forget -V (since some applications use -v for verbose)
- vimax 7y ago
  This is java, it would be -D-XX:VerboseRuntime=true
  - needusername 7y ago
    -XX is for implementation specific VM flags an generally uses + or - -D is for system property and uses key value so it would either be -XX:+VerboseRuntime or -Djdk.runtime.verbose=true
Jenz 7y ago
I laughed a lot at this one
deleted 7y ago
[deleted]
h1d 7y ago
And then some tools use a sub command instead of just being the obvious '-v' but 'version'.

chubot 7y ago

I think that's a good idea, but even if BSD developers accept them and POSIX changes, we'll still have deployed systems for decades that support only short options. This situation reminds me of the dictatorship of the minority: https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15 https://medium.com/incerto/the-most-intolerant-wins-the-dict... I think a more deployable solution is to write shell function wrappers for all POSIX utils that support GNU-style options. I just filed this as an issue for Oil: https://github.com/oilshell/oil/issues/464 https://github.com/oilshell/oil/issues/464 Note that I also plan to provide long options for all shell builtins, mentioned here: https://news.ycombinator.com/item?id=20724924 https://news.ycombinator.com/item?id=20724924 I'm looking for feedback on Oil from experienced shell users! It takes 30-60 seconds to build and install. https://www.oilshell.org/release/0.7.pre3/ https://www.oilshell.org/release/0.7.pre3/ ----- edit: As mentioned on the issue, busybox and toybox (Android) are probably even less likely to change than POSIX/BSDs. So I do think the solution realistically belongs in the shell.

big_chungus 7y ago
Busybox has good reason not to change. It's focused on being lightweight and embeddable, not being user-friendly. It would have to catch both types of flags to maintain compatibility, and parsing for long flags is definitely more complex. Coreutils are different, but busybox is fine with short flags. By the way, oil does look interesting. One key issue is you really need to move to python 3 asap. 4 months and change before it's no longer supported. Plus, people want fancy unicode stuff in shells these days, and that's much easier in python3. Out of curiosity, do you think python vs c will have a major impact on performance? On the other hand, I figure stricter semantics means more room for optimization and slow-down on corner cases. Are there any performance numbers I can look at?
- chubot 7y ago
  Yes, I'm suggesting that busybox can be kept the same, and the parsing can happen in the shell. I get a lot of comments like yours about Python, but they aren't accurate. This FAQ only helps sometimes, but in case it does: http://www.oilshell.org/blog/2018/03/04.html#faq http://www.oilshell.org/blog/2018/03/04.html#faq tl;dr You're mistaken about Unicode; forking in open source is sometimes a feature, not a bug. Also: http://www.oilshell.org/blog/2019/06/17.html#toc_1 http://www.oilshell.org/blog/2019/06/17.html#toc_1

big_chungus 7y ago

In no small part this is because parsing long opts can be significantly more complicated than short ones. It is by contrast very easy to parse short, single-letter flags. Not saying it's not worth doing, but there is a reason this has not been standardized.

dwheeler 7y ago
Parsing long opts is trivial; just determine if the string exactly matches. E.g., "--version" only matches "--version". Short opts is what takes slightly more effort, because you have to accept both "-ld" and "-l -d". We already handle the "hard" case, we just need to support the easy case.

Jenz 7y ago

I cannot imagine how having both long and short options flags can not be portable. Care to enlighten me?

h1d 7y ago

The posix decision is quite dumb. You can't possibly read scripts well with bunch of single letter options. Codes are supposed to be readable.