Knowing the Shell Is 20% Syntax and 80% Toolbox
Telling a Computer to Do Things
A developer reflects on how learning to script the shell transformed his ability to automate tasks, moving beyond one-off commands to loops, conditionals, and pipelines. He argues that shell proficiency is less about syntax and more about knowing tools like fzf, xargs, and rsync. Even experienced engineers often rely on GUIs, limiting what they can automate. He suggests alternatives like zx for JavaScript teams.
I’d argue that knowing the shell is 20% syntax and 80% having a good toolbox.
- mplanchard
Totally agree, and also this was one of the most powerful aspects of using nix development environments: when everyone is guaranteed to be on all the same (recent) versions of bash, make, awk, sed, and any other system deps, you can confidentially write your scripts knowing the whole team can use them, without having to deal with Mac users’ scripts breaking because their bash is old, or because somebody doesn’t have jq installed, or whatever.
- utopiah
Right, and I would also argue that scripting goes way beyond the terminal.
Scripting in the terminal can manipulate windows too (e.g. xdg-open with KWin), or send notification locally (e.g. notify-send) to any devices (again or ntfy), or open dialogs (e.g. kdialog), or controlling other devices (e.g. curl to HomeAssistant API) so indeed it opens up an entire new world of possibilities... and it's combinatorial.
Also for another bit of context, scripting works ... on the weirdest newest devices, e.g. a Meta Quest on Android thanks to Termux. If there is an OS there is surely a terminal in there somewhere, and if there is, you can script on it. So... scripting isn't "just" for your desktop or a remote server, it's everywhere.
- happyPersonR
I’m going to say something … and it might trigger folks
Learning and getting good at shell scripting is something that takes a while usually. I would recommend that people new at shell scripting actually try to use Python instead writing shell scripts where possible.
I’ve seen people not use traps, not know when to use set properly, xargs if you don’t know what you’re doing with it is just a giant foot cannon, and folks new at shell scripting don’t know how to debug running shell processes.
They may have learned some or all of these things for python?(please? )
- adityaathalye
IMO, a scripting language is the lesser contributor to the power of shell scripting. My ranked-order is:
1. Universal Inter-Process Interface: Arbitrary program composition via the Standard Input / Output / Error interface, and "everything is a file" abstraction... None of the rest is possible without some such core design decision ("everything is an object" is the fraternal twin).
2. Widespread standard utilities: The broad availability of core util tools designed to cooperate via the same abstraction is a close second. Along with some default scripting language, that is also built for the same computing model.
3. Language of choice: Important for ease of access, but a distant third in terms of raw power, be it bash, perl, awk, node, clojure (babashka) etc. That's icing on the cake, because if one had no choice in the matter, the shell program would still be awesomely powerful. Proof is in the pudding---"scripts that matter" are always /bin/sh.
Generally speaking, the pain of learning to avoid sh and bash footguns is primarily a matter of some basic research reading: manuals, lore, and warnings (I love BashPitfalls). Well, either that, or learning the hard way by copy-pasting code, and if luck runs out, rm -rf ing something you shouldn't have.
There is no substitute to taking the day or so to read the manual, so you know it's a lot, but it ain't magic, and you can eat that elephant one bite at a time, at your own pace. Seriously... the wall-clock time of trial and error with […]
- necovek
I was pretty close in guessing what they believe was "wrong" (or really, superfluous) with their initial shell script example.
I'd even drop the "if" from their footnote version, and go with simply
npm install || (echo "boom" && exit)
(Not exactly equivalent because there won't be an "exit" if echo fails, but it's my preferred instict over ";") Also, "(" starts a subshell, if we are being pedantic.