3 ms·

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

by koolba 3y ago

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.

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

by koolba 3y ago

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

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.