Telling a Computer to Do Things

Telling a Computer to Do Things will-keleher.com

If you don't know the shell, it's more difficult to tell a computer to do things.

91 points•vismit2000•11 days ago•37 comments•

37 comments

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 BashPitfalls (about a day or so), is nothing compared to learning to use---and then having to re-learn every so often---the python or node or whatever ecosystem without losing it. Besides, the former knowledge is stable and so are the programs --- my Bash code will keep working the same way, forever, practically speaking.

happyPersonR10 days ago

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? )

johnisgood10 days ago

But you gotta learn about processes, signals, job control, traps, exit statuses, pipelines, file descriptors and all those things though. Shell is still a great glue language that helps with that. Learning Python does not really replace knowing how the shell and Unix process model work. It could, but try translating some very short shell commands into Python and see how much more machinery you need!

My 2 cents. :)

marcosdumay10 days ago

> They may have learned some or all of these things for python?(please? )

On other languages those things are either obvious because you have to write the behavior yourself, or fail loudly in a way that requires you to learn them before your code will run.

You don't have to hope. The same people that fall to the foot-guns in sh don't make the same mistakes when they write it in python.

ElevenLathe9 days ago

The more I learn about shell, the less I reach for it for automation scripts, even ones that mainly exist just to shell out to other binaries. I have written a lot of shell in my life, and it turns out (with 20/20 hindsight) that almost all of it was atrociously dangerous and brittle because there are so many ways to screw it up and I didn't know most of them at the time (and still probably don't!).

necovek11 days ago

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.

Sharlin11 days ago

I wonder if there’s some obscure syntax for "do this if the preceding command fails and propagate its exit code". For just returning some error you can of course have something like `die("boom")` (though not as a builtin?) but sometimes it’s useful to know the exact code.

necovek10 days ago

  test 1 == 2 && echo "ok" || (error_code="$?"; echo "failed with '$error_code'"; exit "$error_code")

When command (test 1 == 2) fails, it goes to the "or" section, sets the error_code variable, does something (echo command, but it could be anything), and then re-exits with the same exit code.

It's not so obscure, there is just no native "re-raise" function so you have to record the exit code yourself (actually, bash's built-in exit will return the last command's exit code, but in the example above, that's the "echo" which actually succeeds).

Edit: since the above runs it in a subshell, $error_code is not available outside the parentheses but if you need this, you can try:

  test 1 == 2 && echo "ok" || error_code="$?" && echo "failed with '$error_code'"
  exit $error_code

dasyatidprime11 days ago

if table --warble farble; then :; else table_ec=$?; echo "Garble warble farble! :(" >&2; exit $table_ec; fi

Works in dash/bash/zsh at least; not 100% sure whether the behavior of $? on the command in an if test is mandated by POSIX and/or portable. Note that you can't replace the empty then-branch with a negated condition because the negation also eats the return code.

Also, absolutely correct propagation is essentially impossible (but usually not useful anyway), because some errors might be unexpected signal exits or inability to find the command in the first place, and those will get punned onto other nonzero exit codes. I forget the exact conventions OTTOMH but generally they're in the high half (≥128).

necovek11 days ago

On the higher level question in the article of why do people not use their main languages for basic file and command management?

I believe the answer is the same as to why Python remains hugely popular despite all the well-documented shortcomings: batteries included.

Shell languages include so many neat and concise ways to execute commands, deal with their input, output and exit codes, allow simple traversal of deep directory structures with globs and advanced tools like 'find' or 'xargs', that everything else is very unergonomic.

And niche by default (until it gets used widely enough), so even your LANG-OF-CHOICE-expert you recruit, they will not know a thing about that shell-focused library in LANG-OF-CHOICE.

yjftsjthsd-h11 days ago

Yes, I would say exactly that. Other languages are of course capable of doing all the things that shell does, but in my experience they really suck at doing it in anything resembling an ergonomic and concise way.

utopiah10 days ago

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.

KetoManx6410 days ago

100%! I use ntfy to send commands from within scripts to my android devices. Tasker watches for new ntfy notifications and then executes actions based on them to do things like volume changes, Don't disturb, sending OTP codes, triggering a syncthing resync, etc.

Read the full thread on Hacker News →

37 comments

Related stories