Hacker News Reader

Comment by nfm | Hacker News Reader

They are functionally equivalent, but the longhand versions are clearly more readable/greppable/google-able. The longhand versions have the exact same benefits as calling a variable eg. `target_file` instead of `a`.

View on HN

Usually true but not always. Calling a for loop iterator "index" instead of "i" just adds unnecessary noise, for example.

I think "set -e" in bash should become common on the same level, it's pretty rare that you really want a script to continue after an unguarded error return.

Yes, and you can always set +e if you need to undo it.

I do, however, really despise that you use - to turn these things on and + to turn them off. Without the + you just think of it as being like command line flags, but then you run into +e and the whole thing goes topsy turvy.

I call my for loop variables idx. I never use single letter variable names, though I won't call someone out for it in a small block. Being able to highlight a variable in my editor, even when it's only used in a 5 line block of code is useful. Highlighting all letter i's is not.

\<i\>

It's a lot easier for my fingers to type /idx than /\<i\> and it also easier to scan for idx than i. I'm not saying that everyone should do as I do but I find it frustrating dealing with single letter variables personally.

I agree /\<i\> is a slight pain. Often the easiest way to get there is getting the cursor on one of the i's and hitting *.

What kind of editor are you using?! Any decent ide will give you syntax aware highlighting of selected variable, not word, and even most simple text editors highlight words separated by spaces, commas etc. I've never seen an editor that highlights the exact selection. I have actually missed that feature once or twice but for coding the other behavior is usually much more preferable.

I just use vim.

I set both those options in every script i write. So i do it like this:

  #! /bin/bash -eu

Because i do it in every script, readability and greppability are not important to me; i just need to apply the flags and get on with the script. Taking up two whole lines for them just adds noise.

If i was more selective in my use of those flags, then i would agree that the long forms were preferable, for the reasons given.

causing your script to run incorrectly as `bash script`.

Does bash check the flags in the shebang if you run it with bash instead of directly?

One drawback with this is that if you, or someone, does

  % bash script.sh

to run your script, then the shebang line will never be seen, and your script will run with -e off. If the "set -e" is explicitly given, this won't happen.

As you can guess, I've done this by mistake. One case is after transferring or unarchiving files where execute flags get turned off by mistake. Or using utilities, like job schedulers, that are tricky in whether they run the script as an executable, or via a shell interpreter.

Bash scripting is one of those domains that people just randomly enter without a full walk through the documentation. It's one of those things that almost everybody learns by copy and paste.

Given that, I think it's nice to be a bit more explicit, as it means the person who reads your script to copy and paste a bit out of it is more likely to learn something new in the process.

Not that the copy and paste approach to learning a language is good, but that's how these things typically go in practice.

Agreed. It's like

. ./file

versus

source ./file

Try googling for that if your Google foo is weak. "shell script dot"? "bash dot"? (edit: it seems Google search has gotten smarter or probably has an improved profile for me since this time it actually points to somewhat useful stuff; last time I searched for this was 8 or so years ago)

I had problems getting an upstart script to recognise 'source' - it had to be . ./foo. From memory, 'source' is a bashism.

I would argue they make the code less readable, merely because they are not the original names. I certainly had no idea what "set -o errexit" did—I've never ever seen it in the wild and it doesn't sound familiar to me at all (and I've done a lot of shell scripting).

But "set -e"? Oh yeah, I use that all the time. It also has the benefit of being the same name as the command line option. That's especially useful for "set -x" which I use all the time when debugging bash, especially in the form "bash -x myscript".

I would never say "tar --extract --file" either–it's just not done.

I think "set -e" may be more idiomatic. While not scientific, there are more instances (by about an order of magnitude) of "set -e" than "set -o errexit" found via a code search on GitHub.

Anecdotally, I've nearly always seen "set -e" in bash scripts I've worked with over the years (if the option is there at all).

Reply on news.ycombinator.com