I 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.
Working with large amounts of files or analyzing the content of large files. Not only will you be faster in glueing commands together with pipes but tools like find, grep, sed, awk, cut and so on will also perform much much better than interpreted languages.
Also, I'd never prefer using the stdlib of Python/Ruby/etc for system commands like cp/chmod etc. It takes way more boilerplate code than a oneliner.
You can without too much work build a Python DSL which makes stuff like executing those oneliners as easy as x("cp", "foo", "bar"). And then you never have to worry about quoting command arguments again.
Certainly not impossible but I don’t often have to deal with large amounts of files in circumstances where the performance hit matters to anyone. And while I know sed, awk, etc are powerful, I don’t know them & I’d have to learn how to use them, whereas I do know Ruby & Python.
At the very best this is an edge case where one would have reason to choose shell scripts over scripting languages.
> 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.
Because you can run your bash scripts with Oil. The tagline is:
It's our upgrade path from bash to a better language and runtime. [1]
It's basically the same as JS -> TypeScript, or PHP -> Hack. It's a saner language (and runtime) that runs existing code.
-----
Shell is good for creating Unix systems because of the tools it provides. Ones that deal with the file system and heterogeneous processes (i.e. stuff you didn't write in different languages).
It's hard to explain, but if you work in that area, you'll very quickly see it. You could also do something like Linux From Scratch [2] and it will be very clear why shell is used.
Seems like a big part of why shells are so much better for certain tasks is because of a failing of more general purpose languages. Working with the filesystem, spawning processes, and orchestrating io streams. Shells could almost be considered DSLs for these things, plus some session / state management.
So I think a good question is this: why can't we make these things equally easy to do in a more general purpose language?
Because on the shell side you want simplicity and on the programming side you want control. Shell pretty much has to default to "foo" meaning "execute command foo from $PATH" or almost every line will have useless overhead. GP language needs to make that explicit or it will be a footgun where you don't know what's a command / variable / function. And that's before we get into how the file descriptors / redirects are handled.
Ok well #1 does not apply to me because I don't write a lot of shell. Ditto #2. So it would be better to understand your case for #3, when is shell the best tool for the job when writing a new script? Why?
Python is a bit clumsy by default when the primary purpose is to run other programs. But, it is easy to write a "run()" wrapper function that works more like a shell. There are modules like "sh" as well to smooth over the bumps.