Comment by dwheeler | Hacker News Reader

Comment by dwheeler | Hacker News Reader

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.

Every time I wind up doing

  > java -v

  > java --version

  > java -version

Don't forget -V (since some applications use -v for verbose)

This is java, it would be

-D-XX:VerboseRuntime=true

-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

I laughed a lot at this one

And then some tools use a sub command instead of just being the obvious '-v' but 'version'.

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-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

Note that I also plan to provide long options for all shell builtins, mentioned here: 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/

-----

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.

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?

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

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

> busybox can be kept the same, and the parsing can happen in the shell.

Busybox includes a shell, ash.

Thanks for linking the FAQ; that clears a lot of things up. I can see how the incredible opinionated of python 3 on the whole unicode mess might be an issue. You're maintaining what you need (the big concern) and have clearly done your homework. Clearly you're pretty invested in it, which makes the project look much more interesting. I will be so happy if some one finally gets shell scripting right.

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.

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.

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.

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

Reply on news.ycombinator.com