5 ms·

https://xkcd.com/927 https://xkcd.com/927 Is there room for a lightweight scriptable language that takes the place of, say, bash/zsh/korn/fish shell scripts?

https://xkcd.com/927 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.

0xdeadb00f 7y ago
I use POSIX /bin/sh exclusively. It's reasonably lightweight but because of this you loose a lot of the "bash-ism"s. There's ways to work around it though, and the pure-sh-bible[1] is great. 1: https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible
chubot 7y ago
That's what Oil is, except it also runs bash scripts and lets you upgrade seamlessly. 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 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 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: https://news.ycombinator.com/item?id=22156151 https://news.ycombinator.com/item?id=22156151
- rane 7y ago
  Once Oil has better documentation I'll probably give it a try. The documents outlined in "Docs I Want to Write" seem promising and are still only visible as drafts in Zulip which requires logging in.
  - chubot 7y ago
    That's fair, in the meantime this post gives some more examples: http://www.oilshell.org/blog/2020/01/simplest-explanation.html 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-language http://www.oilshell.org/blog/tags.html?tag=oil-language#oil-...
- lizmat 7y ago
  > Python 3 and Perl 6/Raku are worse for shell-like tasks than their predecessors! Mainly because of startup time and the string abstaction 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.
  - chubot 7y ago
    Oil has better Unicode support than Python 2 or 3 for shell-like tasks, because of the way file systems, libc, and the kernel work. Explained here: http://www.oilshell.org/blog/2018/03/04.html#faq http://www.oilshell.org/blog/2018/03/04.html#faq which links: http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ 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.
    - lizmat 7y ago
      Unicode support of Raku is grapheme based (NFG or Normalization Form Grapheme). The unicode theory: https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundarie... , about the implementation: https://6guts.wordpress.com/2015/04/12/this-week-unicode-normalization-many-rts/ https://6guts.wordpress.com/2015/04/12/this-week-unicode-nor...
    - Grinnz 7y ago
      Perl (5) is array-of-codepoint based, at the logical level. Those codepoints might be internally stored as their encoded-to-UTF-8-bytes, or they might not, but this does not affect the usage of the string. 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.
tempodox 7y ago
Your use case is unclear, but you may want to look at Tcl?
oweiler 7y ago
Lua. Very small runtime, fast, powerful.
- Aloha 7y ago
  Not installed anywhere by default
  - wodenokoto 7y ago
    If that is a requirement, then you have restricted yourself to shell and bash.
  - jtvjan 7y ago
    Ruby? It's installed by default on Mac OS X and many Linux distributions.
    - tecleandor 7y ago
      From now on, neither perl, ruby nor python will be installed by default on OS X https://news.ycombinator.com/item?id=20109469 https://news.ycombinator.com/item?id=20109469

https://xkcd.com/927 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.

0xdeadb00f 7y ago

I use POSIX /bin/sh exclusively. It's reasonably lightweight but because of this you loose a lot of the "bash-ism"s. There's ways to work around it though, and the pure-sh-bible[1] is great. 1: https://github.com/dylanaraps/pure-sh-bible https://github.com/dylanaraps/pure-sh-bible

chubot 7y ago

That's what Oil is, except it also runs bash scripts and lets you upgrade seamlessly. 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 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 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: https://news.ycombinator.com/item?id=22156151 https://news.ycombinator.com/item?id=22156151

rane 7y ago
Once Oil has better documentation I'll probably give it a try. The documents outlined in "Docs I Want to Write" seem promising and are still only visible as drafts in Zulip which requires logging in.
- chubot 7y ago
  That's fair, in the meantime this post gives some more examples: http://www.oilshell.org/blog/2020/01/simplest-explanation.html 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-language http://www.oilshell.org/blog/tags.html?tag=oil-language#oil-...
lizmat 7y ago
> Python 3 and Perl 6/Raku are worse for shell-like tasks than their predecessors! Mainly because of startup time and the string abstaction 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.
- chubot 7y ago
  Oil has better Unicode support than Python 2 or 3 for shell-like tasks, because of the way file systems, libc, and the kernel work. Explained here: http://www.oilshell.org/blog/2018/03/04.html#faq http://www.oilshell.org/blog/2018/03/04.html#faq which links: http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/ 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.
  - lizmat 7y ago
    Unicode support of Raku is grapheme based (NFG or Normalization Form Grapheme). The unicode theory: https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundarie... , about the implementation: https://6guts.wordpress.com/2015/04/12/this-week-unicode-normalization-many-rts/ https://6guts.wordpress.com/2015/04/12/this-week-unicode-nor...
  - Grinnz 7y ago
    Perl (5) is array-of-codepoint based, at the logical level. Those codepoints might be internally stored as their encoded-to-UTF-8-bytes, or they might not, but this does not affect the usage of the string. 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.

tempodox 7y ago

Your use case is unclear, but you may want to look at Tcl?

oweiler 7y ago

Lua. Very small runtime, fast, powerful.

Aloha 7y ago
Not installed anywhere by default
- wodenokoto 7y ago
  If that is a requirement, then you have restricted yourself to shell and bash.
- jtvjan 7y ago
  Ruby? It's installed by default on Mac OS X and many Linux distributions.
  - tecleandor 7y ago
    From now on, neither perl, ruby nor python will be installed by default on OS X https://news.ycombinator.com/item?id=20109469 https://news.ycombinator.com/item?id=20109469