The Shell Hater's Handbook (2010) | Hacker News Reader

The Shell Hater's Handbook (2010)

shellhaters.org

128 pointssamlambert53 comments

YouTube link for video if it's broken for others and not just me:

https://www.youtube.com/watch?v=olH-9b3VJfs

Something I learned recently is that the Bourne shell (and by extension, bash and POSIX's sh) have syntax inspired by Algol 68 (source [0]), which explains some of the funkyness. One thing I've been doing recently is writing scripts in rc, the default shell for plan9. It's a bit saner syntax-wise IMO. Versions linked against readline have file-based completion, but it's otherwise not quite robust enough for me to switch away from fish as my default, but it has some things I prefer over both bash and fish.

I encourage people to give rc and awk a shot, they're both small and learnable in an afternoon!

[0]: https://doc.cat-v.org/plan_9/4th_edition/papers/rc

The Bourne shell was hilariously written in horribly deformed C resembling ALGOL by way of macros:

https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh...

https://news.ycombinator.com/item?id=22191790

That's amazing

Influence of Algol 68 doesn't even really explains requirement of semicolons (or equivalently, new lines) in weird places.

    while false do echo 1 done
    if false then echo 1 fi

argubaly should just work, the presence of do/then/done/fi keywords makes semicolons quite superfluous yet the correct forms are

    while false ; do echo 1 ; done
    if false ; then echo 1 ; fi

Which is strange, because Algol's grammar actually prohibits ; before ELSE, FI, and OD keywords yet the Bourne shell requires them!

Well, to be fair, the use of semicolons in the shell has nothing to do with their use in other languages, here they are simply line separators.

> One thing I've been doing recently is writing scripts in rc, the default shell for plan9. It's a bit saner syntax-wise IMO

I'll stand on the point that if you're gonna forego (ba)sh compatibility, 95/100 times you might as well write Python scripts. Shell syntax generally sucks, and the only reason we still roll with it is legacy code, universal compatibility, and pipes.

As someone who worked with Python professionally for like 8 years, I wholeheartedly disagree with this. Python is an ok scripting language but it's an awful command script language. The extra ceremony to just invoke another command is a complete non-starter IMO. Ruby handles the cases where a shell script makes sense way better than Python does and I still wouldn't pick Ruby. Rc's syntax is better than ba(sh), which is the point: you get things like pipes and easy commands without some of the cruft.

As someone who also has written my fair share of Python, I completely agree. Piping and subprocess handling are my two main complaints as well.

Managing concurrent processes is arguably also easier in shell scripts, in that you can just append “&” to run stuff in the background and “wait” to sync.

I've grown rather fond of bash in my current role. I work mainly on developer tools and CI pipelines, both of which mean gluing together lots of different CLI tools. When it comes to this kind of work I think it is quite hard to beat the expressiveness of shell scripting. I say this as a former hater of bash and its syntax.

Much credit to copilot and shellcheck, which have made complex bash ever the more write-only language than it already was.

> I've grown rather fond of bash in my current role. I work mainly on developer tools and CI pipelines, both of which mean gluing together lots of different CLI tools. When it comes to this kind of work I think it is quite hard to beat the expressiveness of shell scripting.

Every time I have to express logic in YAML, I miss shell. Shell’s really not great, and it could be improved upon (my vote? Tcl), but it’s so much better than where the industry is these days.

You can't use a shell script or a TCL script to generate the YAML file?

Sure, you can generate the YAML file, but it’s not generally possible to trigger that from the system which wants the YAML file, and you don’t get to integrate with the system’s configuration. Often these systems honestly think that their approach of logic-templated YAML is preferable to a script — for example Helm’s templated Kubernetes YAML.

Few things grind my gears worse than _templated_ yaml. It equivalent of building up a json object using only string concatenation. Most people would raise their eyebrows at that, yet templates yaml is seen as very normal.

I think in part it's a skills mismatch - a lot of devops/sysadmin type folks I encounter, while very talented, are not prolific coders. So code-forward solutions like jsonnet, starlark, dhall, nix, etc. are rather unfamiliar familiar.

It doesn't help that all but one of those languages mentioned are odd little functional languages, increasing the familiarity gap even further.

Thanks.

Bash actually has more warts than competing shells because of its historic stance.

My bugbear is that "alias p=printf" works well in any POSIX shell script, including bash when it is invoked as #!/bin/sh - but when called as #!/bin/bash, the alias (used in a script) fails with an error.

While the Korn shell managed to evolve and comply with the POSIX standard, bash decided to split the personality, so one solution to the above alias failure is to toggle POSIX mode.

Bash was forced to do this, to keep a decade of shell scrips that were written for it working. Pity.

The standard for the POSIX shell looked very hard at Korn, and credits it. Bash is not mentioned.

Huh, why wouldn't that alias work?

Good question. Something to do with interactive mode?

  $ cat l.sh
  alias l=ls
  l
  $ sh l.sh
  file1  file2  l.sh
  $ bash l.sh
  l.sh: line 2: l: command not found
  $ bash -i l.sh
  file1  file2  l.sh

Edit: Ah yes, the man page says so.

> Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt

Thanks, I had no idea. I guess I've never used aliases in scripts, but I would've assumed that they'd just work the same as in interactive mode. Good to know.

Why use an alias in a script? Or in general? Functions work everywhere.

Functions don't work everywhere. Bash functions only work in the current shell context unless exported via an `export -f myfun' statement in between the function declaration and downstream sub-shell usage.

Working example:

  pzoppin() {
      printf 'echo is for torrent scene n00bs from %s\n' "$*"
      trap "printf '%s\n' <<< \"$*\"" RETURN EXIT SIGINT SIGTERM
  }
  export -f pzoppin

  echo -e 'irc\0mamas donuts\0starseeds' \
      | xargs -0 -n 1 -I {} /usr/bin/env bash -c '
  echo hi
  pzoppin "$*"
  echo byee
  ' _ {}

The above will fail miserably without the magic incantation:

  `export -f pzoppin'

Why'd they design an otherwise perfectly usable, mapless language without default c-style global functions? :)

I suppose aliases predated functions. Can't find a reference to support that, though. Just a possible reason.

BTW aliases come from csh, and there they support arguments, which makes them similar to functions.

Aliases are like C macros

    $ alias foo='seq 3 | '
    $ foo cat
    1
    2
    3

Functions are functions

So then use $variables for evil syntactic tricks? That works everywhere. Functions where hygiene counts? Aliases never?

>use $variables for evil syntactic tricks

Can't do that without eval, which is another can of worms. Aliases are fine

Indeed, here are two lines atop my "util.sh" to regularize some strange non-conformant behaviours:

  [ "${BASH:-}" ] && shopt -s expand_aliases
  [ "${ZSH_VERSION:-}" ] && setopt SH_WORD_SPLIT

I typically just give up on weird corners of shell when I find an working version of the same.

For instance -- why would you use "alias" when you can make a function? The syntax is a little weird with functions, but it's a lot more clear what's going on.

The same goes for "test" vs the seeming magic of [ where it seems like [ is language syntax (it's a single character!) when in fact ... it's just another executable that communicates with logic evaluation like anything else (like grep or false).

There are many reasons.

1. Aliases can work with the callee scope.

    alias MY_VAR_MODIFIER='local foo=bar'

    MY_VAR_MODIFIER () { local foo=bar; }

Calling the alias by the name will set the callee's variable foo, while calling the function does nothing (local foo is local to the function and never leaves scope).

It also works similarly for working with the set ($@). You can do `set --` stuff and it works on the scope of the callee.]

Aliases on most shells also don't need to be fully valid _before_ expansion. You can alias a compound command:

    alias foreach='for EACH'

    foreach in $MYVAR #perfectly valid for most shells.

Only ksh93 will complain about it, it requires aliases to be complete valid shell programs.

Finally, alias calls don't appear in xtrace (set -x). Only the final expansion will appear.

TL;DR aliases in scripts work a lot like macros.

Gluing together tools with shell scripts is a significant cause of CI failures in my experience. There's no reason to do it. Use a real language - at least Python, but my preference is Deno because it's not dog slow and you don't have to deal with venv.

I mean I guess but what's your plan when your script is just a bunch of subprocess.run calls? I promise you it won't be any less brittle.

The subprocess.run args argument is a list of strings, not a single string with whitespace-delimited parts, so you're all good quotingwise. This is now effortlessly a lot better than what you get with bash in terms of how brittle things are!

Supply check=True and the script will barf on subprocess failure. Another useful upgrade.

subprocess.run() will happily accept a single string, though, so you may still inadvertently run into the issue anyway.

Take a look at https://sh.readthedocs.io/en/latest/ for a very usable solution to easily run other processes in Python. It has made my life a lot easier whenever I've had to migrate a shell script to Python.

I promise it will! It will handle weird filenames properly for example.

But realistically it's rarely that simple and even when it starts that simple it will grow to not be.

The downvotes are a very disappointing attitude.

Shellcheck will prevent you from making any egregious whitespace errors. You can dynamically build up an arguments list using bash arrays. Errexit and pipefail options prevent you from ignoring errors.

I agree that some work is better suited to a real programming language, however the driving force isn't the problems you speak of, which are trivial, it's when the logic/control flow of the overall problem becomes more complex.

> Shellcheck will prevent you from making any egregious whitespace errors.

It will try to prevent you. It isn't perfect though, and whitespace errors are only the tip of the iceberg.

Shellcheck doesn't tell you to enable pipefail for example, so there's a huge foot-gun.

Pipefail itself is kind of impossible to use correctly anyway.

(2010)

Sadly the video seems to be missing; the whole GoGaRuCo conference site is gone, actually.

Maybe it makes more sense to post the link to YT, as you did in 2022 https://news.ycombinator.com/item?id=32521080

> Maybe it makes more sense to post the link to YT, as you did in 2022

Based on the comments there, it seems like OP posted this current (shellhaters.org) link then too, and it's the mods that replaced it to point to the YouTube video. Hopefully the same will happen this time around as well.

I tried following the slide deck (to get an idea of the content), but that's pretty rough too. The page reloads itself constantly and is very inconsistent with responding to input keys, it's not a pleasant experience.

Thanks for the (indirect) link to the YouTube video, will give that a try.

And its inspiration is still great but could use a refresh: https://web.mit.edu/~simsong/www/ugh.pdf

A brilliant historical artifact, and the irony that macOS has been Unix for most of the Mac's existence, and that Windows has included POSIX and/or Linux for most of its existence, is not lost on me.

The Dennis Ritchie anti-forward makes it even better:

> The rational prisoner exploits the weak places, creates order from chaos: instead, collectives like the FSF vindicate their jailers by building cells almost compatible with the existing ones, albeit with more features. The journalist with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred.

Thanks for reminding me about this gem! :)

Getting a DNS error from confreaks.

You can get the video here:

* https://web.archive.org/web/20140207100122/http://confreaks....

A video is not a handbook. A handbook is a book. There's a clue in the name.

Life is too short for videos.

I'm not familiar with the landscape - is there a "compiles to reasonably-readable [ba]sh" language that's gotten any traction anywhere? That seems like at least an interesting possible solution.

There was a pretty great-looking one that I saw on HN in the last few months. I didn’t end up trying it, and I don’t remember what it was called.

There’s also babashka, which pretty much let’s you write clojure in your shell scripts.

Might have been Oil shell, which is worth looking at: https://www.oilshell.org/

Oil shell is the way forward for shell.

The only problem I have with it is that the author is terribly fond of weird self-referential puns and wordplay, and I find the docs (and posts and comments) he writes to be basically unreadable.

Even the project names: osh, and ysh, and oils, where osh is short for Oil Shell, but so is OilS I think...

It makes it really annoying and difficult to read, IMHO. Maybe it's just me.

Was it https://amber-lang.com?

If you're a shell hater, the answer isn't to write MORE shell, but to switch to something else, for the love of all things sane and normal.

The trouble is that all the existing xNix GUI shells suck. They suck in widely varying degrees, from ones that could suck a bowling ball through an iron water pipe, like GNOME and KDE, to ones that could merely suck a golfball through a hosepipe, like Unity and Xfce, but they all suck.

There have been GUI shells that didn't perceptibly suck at all, such as early versions of the Windows 9x shell, classic MacOS, and Acorn RISC OS, but they're all largely dead and gone now.

Well, I meant people should use a real programming language. Also, I'm not sure why "bash with a real programming language syntax" isn't a thing. Apparently last time this was tried was the "C Shell" which had c-like syntax? Why don't we have a javascript-like syntax for a shell yet?

Er. I think we're at cross purposes.

What do you mean by the word "shell"?

I mean "the user interface of the OS" which implies nothing about whether it's text, graphics, both, spoken word, gestural, whatever.

Reply on news.ycombinator.com