There's just certain types of tasks where you can more clearly express your intent in a shell script. If, for example, you need to spawn a ton of subprocesses, you can do that in any scripting language, but shell is designed from the ground up to launch subprocesses — it's most basic purpose is to launch programs.
And so while I can't give an example of something that can only be done in a shell script, here's a shell script that I wrote a few weeks ago that would have been a pain in the neck to express in any other language:
#!/bin/sh
cd "$(dirname "$0")"
for test in *.in; do
test="$(basename "$test" .in)"
infile="$test.in"
outfile="$test.out"
output="$(./whofrom "$infile" 2>&1)"
expected="$(cat "$outfile")"
if [ "$output" != "$expected" ]; then
echo "Failed test $test"
echo "Expected: $expected"
echo "Actual: $output"
echo
fi
if ! valgrind --error-exitcode=1 --leak-check=full ./whofrom "$infile" 2>/dev/null >/dev/null; then
echo "Failed test $test"
valgrind -q --leak-check=full ./whofrom "$infile"
echo
fi
done #!/usr/bin/env python
import sys, os, subprocess, glob
os.chdir(os.path.dirname(sys.argv[0]))
for test in glob.glob("*.in"):
test = os.path.splitext(test)[0]
infile = test + ".in"
outfile = test + ".out"
output = subprocess.check_output(["./whofrom", infile], stderr=subprocess.STDOUT)
expected = open(outfile, 'r').read()
if output != expected:
print("Failed test", test)
try:
devnull = open(os.devnull, 'w')
subprocess.check_call(["valgrind", "--error-exitcode=1", "--leak-check=full", "./whofrom", infile], stderr=devnull, stdout=devnull)
except subprocess.CalledProcessError:
print("Failed test", test)
subprocess.check_call(["valgrind", "-q", "--leak-check=full", "./whofrom", infile])
Apart from the header, the whole script is pretty much the same when comparing line-by-line.
How do you find which module you need? Search on the web may be the best answer. In shell at least you have "man -k".
Once I know the module, how do I get its documentation? Here at least there is an answer: import glob; help(glob);
But how good is this documentation? If I do it I get:
glob(pathname)
Return a list of paths matching a pathname pattern.
The pattern may contain simple shell-style wildcards a la fnmatch.
The shell script started as a workflow that was executed repeatedly, manually, from the shell, and then automated. Naturally, the shell script resembles very closely they commands typed in at the shell, with some added code to encode the part of the routine that was executed in the user's head.
The python script doesn't look anything like the routine that was previously entered at the shell. That makes it harder to tell at a glance that this script does the same thing.
It it horrible? No absolutely not. If you're working on a team where everyone knows python but not everyone is comfortable with shell scripts, then writing the script in python is the clear best option. But if you're working on a team where everyone is comfortable with both python and shell scripts, the shell script probably wins out.
Install perl/python/ruby and nodejs -- requiring just the shell to be installed?
Snark aside (it's not only snark - pretty much every system will have something like a posix shell), proper posix portable shell is hard - it's an old gnarly language -- but it's what we've got. And with a bit of discipline and good practices -- it doesn't have to be bad. That said, a lot of real-world shell scripts are bad.
I tend to agree with the overall sentiment; shell isn't a great language. As soon as you start to mix awk (which awk is that, do you need GNU awk?), sed and perhaps a bit of egrep (or grep -E -- are both available? Does it accept only BSD-style parameters?) -- one should consider moving "up".
And for eg: setting up a python package/program -- I'd generally prefer a python script -- hopefully one that handles different file-paths (eg: / vs \ ) and other cross-platform stuff. If you already depend on python, why add dependency on shell?
I just meant using any one of them, not all of them. And you can pretty much always rely on python and perl being installed.
But my point is that if you're doing something other than a one-off thing, then it belongs to some project and you're probably going to commit that script to that project's codebase. That means it has to be maintained. Do future you and whoever else has to maintain the project a favor and use one of the popular scripting languages that has reasonable syntax and semantics.
Personally I'd much rather maintain a shell script than a perl script - but that's just because I know shell better. Maybe shell is the first language people would program without learning it (js being the second)?
You can run several of those languages (python for sure, but also perl IIRC) as a shell.