Telling a Computer to Do Things

Join the discussion

• Hacker News
• There is, of course, a programming language designed to do shelly things as succinctly as a shell script: Perl.
  by Sharlin
• TIL that the duckdb REPL supports reading json files (https://duckdb.org/docs/current/data/json/overview). This might actually be useful the next time I need to investigate a massive json file (`jq` can only go so far).
  by ccapitalK
• I was sure this article would be about how we tell computers to do things now (writing prompts to an AI in plain English). I was wrong. Interesting nonetheless.
  by carra
• 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.

  by utopiah
• 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.

  by 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.
  by necovek
• 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? )

  by happyPersonR
• 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.

  by adityaathalye