3 ms·

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 opti

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

by chubot 7y ago

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