The Shell Hater's Handbook (2010)
126 points by samlambert 6 days ago | 51 comments
  • genezeta 6 days ago |
    (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

    • sundarurfriend 6 days ago |
      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.

    • sundarurfriend 6 days ago |
      > 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.

  • Eisenstein 6 days ago |
    Getting a DNS error from confreaks.

    You can get the video here:

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

  • packetlost 6 days ago |
    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

    • Rendello 6 days ago |
      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

      • packetlost 6 days ago |
        That's amazing
    • Joker_vD 5 days ago |
      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!
      • Koshkin 4 days ago |
        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.
    • jorvi 5 days ago |
      > 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.

      • packetlost 5 days ago |
        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.
        • setopt 5 days ago |
          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.

  • yanowitz 6 days ago |
    And its inspiration is still great but could use a refresh: https://web.mit.edu/~simsong/www/ugh.pdf
    • alkh 6 days ago |
      Thanks for reminding me about this gem! :)
    • musicale 6 days ago |
      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.

  • hamandcheese 6 days ago |
    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.

    • chasil 6 days ago |
      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.

      • mort96 6 days ago |
        Huh, why wouldn't that alias work?
        • photon-torpedo 6 days ago |
          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

          • mort96 6 days ago |
            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.
            • RhysU 6 days ago |
              Why use an alias in a script? Or in general? Functions work everywhere.
              • sudahtigabulan 6 days ago |
                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.

              • oguz-ismail 6 days ago |
                Aliases are like C macros

                    $ alias foo='seq 3 | '
                    $ foo cat
                    1
                    2
                    3
                
                Functions are functions
                • RhysU 6 days ago |
                  So then use $variables for evil syntactic tricks? That works everywhere. Functions where hygiene counts? Aliases never?
                  • oguz-ismail 6 days ago |
                    >use $variables for evil syntactic tricks

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

              • metadat 5 days ago |
                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? :)
          • BoingBoomTschak 5 days ago |
            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
      • cduzz 6 days ago |
        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).

        • alganet 5 days ago |
          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.

    • IshKebab 6 days ago |
      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.
      • Spivak 6 days ago |
        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.
        • tom_ 6 days ago |
          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.

          • KingMob 2 days ago |
            subprocess.run() will happily accept a single string, though, so you may still inadvertently run into the issue anyway.
        • iamjackg 6 days ago |
          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.
        • IshKebab 5 days ago |
          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.

          • hamandcheese 5 days ago |
            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.

            • IshKebab 5 days ago |
              > 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.

    • eadmund 6 days ago |
      > 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.

      • hollerith 6 days ago |
        You can't use a shell script or a TCL script to generate the YAML file?
        • eadmund 5 days ago |
          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.
          • hamandcheese 5 days ago |
            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.

          • hollerith 5 days ago |
            Thanks.
  • nlawalker 6 days ago |
    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.
    • chamomeal 6 days ago |
      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.

      • bewuethr 6 days ago |
      • dmckeon 6 days ago |
        Might have been Oil shell, which is worth looking at: https://www.oilshell.org/
        • simonmic 5 days ago |
          Oil shell is the way forward for shell.
          • lproven 5 days ago |
            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.

  • lproven 5 days ago |
    A video is not a handbook. A handbook is a book. There's a clue in the name.

    Life is too short for videos.

  • phendrenad2 4 days ago |
    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.
    • lproven 3 days ago |
      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.