5 ms·
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 t
by 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 agoYes, 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.