https://xkcd.com/927
Is there room for a lightweight scriptable language that takes the place of, say, bash/zsh/korn/fish shell scripts?
Please don't say perl/python or sed/awk.
Is there room for a lightweight scriptable language that takes the place of, say, bash/zsh/korn/fish shell scripts?
Please don't say perl/python or sed/awk.
That is, bin/oil is the same as bin/osh with a bunch of shell options on, including 'shopt -s simple_word_eval' which eliminates a lot of the quoting hassles.
You can try it now, but some things will be cut out after optimizing the prototype interpreter (in the name of time):
You Can Now Try the Oil Language http://www.oilshell.org/blog/2019/10/04.html
I'm looking for help too: http://www.oilshell.org/blog/2019/12/09.html#help-wanted
----
Also, I think there is more room than ever, because both Python 3 and Perl 6/Raku are worse for shell-like tasks than their predecessors! Mainly because of startup time and the string abstaction.
We discussed that a couple weeks ago here, and I think it's on the blog somewhere too:
http://www.oilshell.org/blog/2020/01/simplest-explanation.ht...
as well as other posts tagged #oil-language:
http://www.oilshell.org/blog/tags.html?tag=oil-language#oil-...
Startup time can always be better, agree. But full support for Unicode is needed in this day and age, and that brings overhead, whichever way you do that, and especially so if you want to do it 100% correctly. If you're still living in an ASCII world, then by all means, go for it.
Additionally, in this world of source version control, and virtually unlimited diskspace for source-code, I think using scripts, rather than one-liners, will help better in maintainability rather than using one-liners.
Explained here:
http://www.oilshell.org/blog/2018/03/04.html#faq
which links:
http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ (by Armin Ronacher)
The summary is that there are two kinds of Unicode support:
- UTF-8 based: Go, Rust, and Oil (and Perl 5 it seems, not sure about Raku)
- array-of-codepoint based: bash/zsh/libc, Python, Java, JavaScript, Windows (JavaScript notably requires surrogate pairs, Python used to have build time configuration, now has complex storage heuristics, etc.)
This isn't a theoretical problem -- the Unicode problems in the other comment thread I linked are real and show up in practice.
Many don't really understand the string model (because many don't really understand character encoding) but it comes down to: all input and output is going to be bytes, which by default is stored as the codepoints sharing the ordinals of those bytes, and there are several mechanisms by which you can manually or automatically decode/encode those byte ordinals to the represented characters; for most text processing, you do this on STDIN and STDOUT.
Most of what people hope for Unicode support to achieve beyond that (case-folding, homoglyph elimination, &c.) is not only not achieved, but not even possible.