6 ms·

They are functionally equivalent, but the longhand versions are clearly more readable/greppable/google-able. The longhand versions have the exact same benefits

by nfm 12y ago

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`.

stormbrew 12y ago
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.
- dsfadadsffd 12y ago
  Yes, and you can always set +e if you need to undo it.
  - stormbrew 12y ago
    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.
- gmjosack 12y ago
  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.
  - dllthomas 12y ago
    \<i\>
    - gmjosack 12y ago
      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.
      - dllthomas 12y ago
        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 *.
  - Too 12y ago
    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.
    - gmjosack 12y ago
      I just use vim.
- twic 12y ago
  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.
  - Hello71 12y ago
    causing your script to run incorrectly as `bash script`.
  - stormbrew 12y ago
    Does bash check the flags in the shebang if you run it with bash instead of directly?
  - mturmon 12y ago
    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.
- nhaehnle 12y ago
  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.
pmh 12y ago
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).
oblio 12y ago
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)
- vacri 12y ago
  I had problems getting an upstart script to recognise 'source' - it had to be . ./foo. From memory, 'source' is a bashism.
__david__ 12y ago
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.

by nfm 12y ago

stormbrew 12y ago

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.

dsfadadsffd 12y ago
Yes, and you can always set +e if you need to undo it.
- stormbrew 12y ago
  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.
gmjosack 12y ago
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.
- dllthomas 12y ago
  \<i\>
  - gmjosack 12y ago
    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.
    - dllthomas 12y ago
      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 *.
- Too 12y ago
  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.
  - gmjosack 12y ago
    I just use vim.
twic 12y ago
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.
- Hello71 12y ago
  causing your script to run incorrectly as `bash script`.
- stormbrew 12y ago
  Does bash check the flags in the shebang if you run it with bash instead of directly?
- mturmon 12y ago
  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.
nhaehnle 12y ago
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.

pmh 12y ago

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).

oblio 12y ago

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)

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

__david__ 12y ago

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.