Hacker News new | past | comments | ask | show | jobs | submit login
Corner cases and shell scripts (rachelbythebay.com)
11 points by llambda on Feb 11, 2013 | hide | past | favorite | 4 comments



It's the shell scripts that update software (outside the package manager) that make my blood run cold; their mv and rm and sometimes rsync commands can give you a pretty bad day when they go wrong.

Oddly, where things like config scripts are concerned, I've been more annoyed by software that tries to verify the contents of the script (except where visudo is concerned of course). It can get in the way, forcing me to deal with sorting out some particular bit of syntax immediately or else abandon all changes when really I just need to put that file aside for a moment and deal with the other service that just burst into flames. I wish I could recall the specifics, but I just dealt with this exact situation recently, and I would've liked to have had a "tazer" button on my keyboard for the developer responsible for that feature.

Aside: as a fellow troubleshooter, I have a huge amount of respect for rachel's content and skills. Her stuff is often a treat.


“I mean, who really switches on the option to make it die on unset variables?”

I thought rachelbythebay has worked at Google, whose internal Bash style guide recommends these settings:

    set -o nounset  # (aka set -u) abort on undefined variable reference
    set -o errexit  # (aka set -e) abort on any command failure
It may have also recommended enabling xtrace with line numbers, but I don’t remember.


I did. I've also seen incredible abuses of said scripts.

I'm talking about scripts that do things like unzipping (Python) PAR files, patching things they find inside, then running them to accomplish their own goals. The number of dependencies that introduced was just amazing.

You really don't want to know how the sausage is made.


Even if you can't force it on for everything, the bash construction ${variable:?message} lets you error out on individual null or unset values[1]. Unfortunately there doesn't seem to be as simple a way to handle all of null, unset, and empty string as rachelbythebay points out is needed. You can fudge it with a test against ${#parameter} (parameter length), but you don't get the direct error effect.

[1] There are a lot of beautiful strangenesses in bash, especially the Parameter Expansion section of the manpage.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: