5 ms·

After years writing bash scripts I stumbled with this line... set -e Which forces the script to exit on first error. This line be in the bible as Genesis 1:1

koolba 3y ago
Just wait till you learn about: set -euo pipefail That should be line two of every bash script.
- worldsayshi 3y ago
  The more I use bash the less I want to use it. So much UX weirdness. I feel like making the complaints people usually have with JavaScript. I like JavaScript. Because I'm good enough at it to ignore the bad parts. If I get good enough at bash, will it get better?
  - koolba 3y ago
    > If I get good enough at bash, will it get better? Bash itself will not get better because you'll be stuck writing scripts targeting some ancient version to ensure wider compatibility. It's still a powerful skill to develop. It's a sweet spot between a one-off shell pipeline and something that involves actual logic. Bash scripts should not be used for their logic. Think of them as a way to document a series of commands that you do not want to manually type. That can be including long argument names, generating includes or classpaths, or generating log file names based on the current time. A good rule of thumb is if your script involves any if-statement other than parameter validation or basic on-success-of-x-do-y, it probably should be in a real language.
- scns 3y ago
  Used it in every script after learning about it. Might be great if it could be set globally for all Bash scripts.
- chasil 3y ago
  POSIX shells only support: set -eu You might want to be in the dash POSIX shell for raw speed and portability.
- nrclark 3y ago
  -eu? Yes. -o pipefail? Maybe not, for two reasons: 1. Pipefail is a bashism, and doesn't exist on Ubuntu's /bin/sh or Busybox /bin/sh (common on embedded Linux systems) 2. Pipefail invalidates some common shell patterns like "grep _something_ | xargs -r CMD". Pipefail is nice in some circumstances for sure. But it's probably not great advice to automatically copypasta into the top of every shell-script.
  - koolba 3y ago
    > 1. Pipefail is a bashism, and doesn't exist on Ubuntu's /bin/sh or Busybox /bin/sh (common on embedded Linux systems) I wasn't suggesting for a generic posix shell. It's explicitly for bash. If you're going to dumb down to pure posix, it's even more painful as you can't even have local function variables. > 2. Pipefail invalidates some common shell patterns like "grep _something_ | xargs -r CMD". That type of situation is the exception, not the rule. The more common situation is "foo some-input.txt | bar" and you want it to fail if foo fails. > Pipefail is nice in some circumstances for sure. But it's probably not great advice to automatically copypasta into the top of every shell-script. I'd much rather have that type of failure than an inadvertent continuation of a script when something early in a pipeline failed.
  - da39a3ee 3y ago
    I don't agree on -e: see my comment higher up in the thread. It might be ok if you're hyper-aware, but recommending it to others will leave them baffled and confused in situations like that in my example where a non-zero exit is within the bounds of normal behavior of the script.
LikesPwsh 3y ago
The weird defaults are partly down to the different requirements of scripting vs interactive terminal use. The defaults of bash make more sense for terminal use than scripting. Powershell is a bit further towards the scripting end of the spectrum- part of why it annoys people coming from bash. Compiled languages would be at the scripting end.
da39a3ee 3y ago
No. I agree, when I first encountered -e I thought it sounded like a good idea. But it's not too long before the problems rear their heads. #!/bin/bash set -e grep nomatchforthis echo "Won't get here!"
cjvirtucio 3y ago
you could also just write as if you're writing go: function main { if ! failing_cmd; then log "this fails!" return 1 fi log "this won't log" } main I only mention this because there are folks who don't like set -e.

koolba 3y ago

Just wait till you learn about: set -euo pipefail That should be line two of every bash script.

worldsayshi 3y ago
The more I use bash the less I want to use it. So much UX weirdness. I feel like making the complaints people usually have with JavaScript. I like JavaScript. Because I'm good enough at it to ignore the bad parts. If I get good enough at bash, will it get better?
- koolba 3y ago
  > If I get good enough at bash, will it get better? Bash itself will not get better because you'll be stuck writing scripts targeting some ancient version to ensure wider compatibility. It's still a powerful skill to develop. It's a sweet spot between a one-off shell pipeline and something that involves actual logic. Bash scripts should not be used for their logic. Think of them as a way to document a series of commands that you do not want to manually type. That can be including long argument names, generating includes or classpaths, or generating log file names based on the current time. A good rule of thumb is if your script involves any if-statement other than parameter validation or basic on-success-of-x-do-y, it probably should be in a real language.
scns 3y ago
Used it in every script after learning about it. Might be great if it could be set globally for all Bash scripts.
chasil 3y ago
POSIX shells only support: set -eu You might want to be in the dash POSIX shell for raw speed and portability.
nrclark 3y ago
-eu? Yes. -o pipefail? Maybe not, for two reasons: 1. Pipefail is a bashism, and doesn't exist on Ubuntu's /bin/sh or Busybox /bin/sh (common on embedded Linux systems) 2. Pipefail invalidates some common shell patterns like "grep _something_ | xargs -r CMD". Pipefail is nice in some circumstances for sure. But it's probably not great advice to automatically copypasta into the top of every shell-script.
- koolba 3y ago
  > 1. Pipefail is a bashism, and doesn't exist on Ubuntu's /bin/sh or Busybox /bin/sh (common on embedded Linux systems) I wasn't suggesting for a generic posix shell. It's explicitly for bash. If you're going to dumb down to pure posix, it's even more painful as you can't even have local function variables. > 2. Pipefail invalidates some common shell patterns like "grep _something_ | xargs -r CMD". That type of situation is the exception, not the rule. The more common situation is "foo some-input.txt | bar" and you want it to fail if foo fails. > Pipefail is nice in some circumstances for sure. But it's probably not great advice to automatically copypasta into the top of every shell-script. I'd much rather have that type of failure than an inadvertent continuation of a script when something early in a pipeline failed.
- da39a3ee 3y ago
  I don't agree on -e: see my comment higher up in the thread. It might be ok if you're hyper-aware, but recommending it to others will leave them baffled and confused in situations like that in my example where a non-zero exit is within the bounds of normal behavior of the script.

LikesPwsh 3y ago

The weird defaults are partly down to the different requirements of scripting vs interactive terminal use. The defaults of bash make more sense for terminal use than scripting. Powershell is a bit further towards the scripting end of the spectrum- part of why it annoys people coming from bash. Compiled languages would be at the scripting end.

da39a3ee 3y ago

No. I agree, when I first encountered -e I thought it sounded like a good idea. But it's not too long before the problems rear their heads. #!/bin/bash set -e grep nomatchforthis echo "Won't get here!"

cjvirtucio 3y ago

you could also just write as if you're writing go: function main { if ! failing_cmd; then log "this fails!" return 1 fi log "this won't log" } main I only mention this because there are folks who don't like set -e.