Four features that justify a new Unix shell
oilshell.org
Four features that justify a new Unix shell
1–10 of 185 posts
Re: Four features that justify a new Unix shell
#2New shell or not I hope we see updates to existing shells to do better error handling too
Re: Four features that justify a new Unix shell
#3Are there any transpile to bash languages?
I like the idea of a language that allows for a better experience in writing shell scripts -- and produces shell scripts with fewer bugs on the output side.
But i wonder if a transpile approach wouldn't be better in the long run
Re: Four features that justify a new Unix shell
#4I love the direction this wants to go in. So many of these are reasons why we've banned new shell scripts on our projects and instead make python scripts.
Re: Four features that justify a new Unix shell
#5New shell or not I hope we see updates to existing shells to do better error handling too
(author here) Yes, I actually proposed that in the comments [1]. Some should add command_sub_errexit to bash:
echo $(date %x) # can you tell what's wrong here?
echo 'script should fail before this'
local d=$(date %x)
echo 'script should fail before this'
diff The 'run' builtin to fix the "if myfunc" problem should also be adopted by other shells.
POSIX basically calcified broken language semantics and needs to be fixed.
I also document stuff like shopt -s simple_word_eval for other shell implementers: https://www.oilshell.org/release/0.8.3/doc/simple-word-eval....
-----
BTW Oil's code is very short (see comment), and I'm looking for help :) Let me know if you can't get a bin/osh working in 1 to 5 minutes. (If you have a Debian/Ubuntu-ish machine it should take about 1 minute.)
This is a pure Python program that you can quickly modify/prototype, and then for the release it's translated into C++ for a 30-50x speedup [2].
https://github.com/oilshell/oil/wiki/Contributing
[1] https://lobste.rs/s/qfiki1/four_features_justify_new_unix_sh...
[2] http://www.oilshell.org/blog/2020/01/parser-benchmarks.html
Re: Four features that justify a new Unix shell
#6Are there any transpile to bash languages? I like the idea of a language that allows for a better experience in writing shell scripts -- and produces shell scripts with fewer bugs on the output side. But i wonder if a transpile approach wouldn't be better in the long run
What do you think produces the traditional ./configure scripts that you run to configure an open source project prior to building it? Did some human write these ./configure scripts manually?
Re: Four features that justify a new Unix shell
#7I love the direction this wants to go in. So many of these are reasons why we've banned new shell scripts on our projects and instead make python scripts.
Are there ever good reasons to choose a shell script over a Python/Ruby/etc script?
Re: Four features that justify a new Unix shell
#8Are there any transpile to bash languages? I like the idea of a language that allows for a better experience in writing shell scripts -- and produces shell scripts with fewer bugs on the output side. But i wonder if a transpile approach wouldn't be better in the long run
What do you think produces the traditional ./configure scripts that you run to configure an open source project prior to building it? Did some human write these ./configure scripts manually?
Autoconf isn’t flexible enough for general purpose scripting though, is it? So not really relevant I think.
Re: Four features that justify a new Unix shell
#9I love the direction this wants to go in. So many of these are reasons why we've banned new shell scripts on our projects and instead make python scripts.
Are there ever good reasons to choose a shell script over a Python/Ruby/etc script?
Yes, a couple answers here: http://www.oilshell.org/blog/2018/01/28.html#shouldnt-we-dis...
Re: Four features that justify a new Unix shell
#10Earlier quoted context omitted.
Are there ever good reasons to choose a shell script over a Python/Ruby/etc script?
Yes, a couple answers here: http://www.oilshell.org/blog/2018/01/28.html#shouldnt-we-dis...
> It won't work. It would be like trying to convince people who are paid to write PHP not to write PHP. Many people have wasted breath on that, but important sites like Wikipedia are still written in hundreds of thousands of lines of PHP.
If they're gonna keep writing bash, why would a new shell language help?
> Even if a new line of shell never gets written, there will still be a huge installed base of shell scripts that you may need to understand (e.g. when they don't work).
If the old scripts are in bash, why would a new shell language help?
> Shell is still the best tool for many jobs. Most new "cloud" projects rely on Linux system images, in VMs or containers, and shell is the ideal language for creating such images.
What's good about shell for this task?