Why not use Python instead? Shellscript is so... chaotic.
Like the way the shell would fork off an "expr" sub-process to parse a mathematical expression to add two numbers, then write the result to a pipe via stdout, then terminate the process, clean up all its resources, and switch context back to the shell, which then read the serialized sum back in from the other end of the pipe, and went about its business, regardless of the fact that the CPU running the shell already had its own built-in "add" instruction in hardware.
Unless you are over fifty years old, you never experienced this.
Rob Pike said it best: "Those days are dead and gone and the eulogy was delivered by Perl."
Perl being a thing in 1995...
[1] https://github.com/baphomet-berlin/jQuery-basic-arithmetic-p...
Shell scripts are guaranteed to be runnable on all machines.
Unfortunately the shell "language" sucks, but still...
Oh, and be very careful of the commands your script invokes!
shell scripts have no guarantee of portability (often less than Python, which has a rich standard library available on all platforms).
Why do you say that? genuinely curious
I'm curious because these simple things that are delightfully easy in bash often turn out to be surprisingly tedious in other languages.
Of course, some things are tedious in bash too. But a basic principle of shell scripting is that you call other programs to do the stuff you don't want to do in shell.
I agree it is tedious, but to be honest, reading and writing to stdin/out isn't something that would commonly need to be done in a robust system. If the world were perfect you would use library functions.
I definitely think there is scope for a language that works well as an interactive shell, and as a general purpose language. They have somewhat conflicting constraints but I'm sure we can do better than Bash. Have you seen how [ is implemented?
Yeah, a nicer shell-like language would be cool. I've been thinking about it for a while.
Bash is quirky but it gets a lot of stuff right and once you understand it it can be extremely ergonomic and productive.
And not depending on language run times other than shell can be really glorious in some situations, too...
When you're not writing shell, just use the tools the language gives you.
For the matter, I think a shell script is cleaner than a python script for devops; but I don't think the composability of unix tools is that much of an advantage compared to the amount of python libraries out there.
I'm likely to be using Python programs and other programs in those shell scripts. The beauty of shell is that it makes it so easy to compose programs written in different languages.
I think the advantages of using a single language for everything outweigh the disadvantages - see e.g. http://www.teamten.com/lawrence/writings/java-for-everything... (though actually my single language is Scala)
The kinds of scripts I write would be awkward to have as compiled JVM programs, I think. Shell is just way more ergonomic for me for many tasks.
Data can be meaningfully separated from control and structure in many cases, and failure to do that is a major (perhaps the major) source of security bugs.
Shell doesn't enforce any particular interpretation of data. Pipelines simply connect one program's output to another's input. Interpretation is up to the programs.
If these were the only standard protocols that existed, and people were trying to tell me this was great because it's easy to compose different network applications, that criticism would be completely valid.
>Interpretation is up to the programs.
But because there are no standards beyond "stream of bytes", the chance that two independently written programs working with non-stream-like data can communicate directly is extremely low.
But the shell language itself is one of these legacy non-standardized formats. Arcane escaping rules, multiple incompatible implementations, surprising ways things get interpreted as code (e.g. the recent bash CGI bug),...
from subprocess import Popen, PIPE
p1 = Popen(["foo"], stdout=PIPE)
p2 = Popen(["bar"], stdin=p1.stdout, stdout=PIPE)
p1.stdout.close() # Allow p1 to receive a SIGPIPE if p2 exits.
output, _ = p2.communicate()