4 ms·

Interesting list (not very surprising to me personally though saw $REPLY mentioned anywhere after a long time). One that surprised me recently (in a how-come-I-

Interesting list (not very surprising to me personally though saw $REPLY mentioned anywhere after a long time). One that surprised me recently (in a how-come-I-didn't-know-about-it-for-so-long way) was $PIPESTATUS e.g. if you are running a pipeline "cmd1 | cmd 2" and would like to know the return status of cmd1, you can use ${PIPESTATUS[0]} to get that. Useful, e.g. when you are tee-ing the output etc.

teddyh 8y ago
I would recommend against using $REPLY, for two related reasons: 1. It’s confusing to do a plain “read” and later have a magic $REPLY variable show up, seemingly from nowhere. It has shades of Perl, and I mean nothing positive with that statement. 2. Names are good. By setting a name to the thing which is read, you make the later code easier to read. It’s easier to understand “echo $filename” than “echo $REPLY”, so if you’re reading filenames, do “read filename”. (Or, rather, you probably want to do “read -r filename”, but that’s a different subject.)
- daveFNbuck 8y ago
  I don't do a lot of bash programming, but I imagine using $REPLY also increases the danger of having the value overwritten before you use it as your code changes.
  - mar77i 8y ago
    Now that you mentioned it, I never hit the case where I would read two different times in the same function/subshell scope and would never have considered this a problem. But maybe I'm just preempting this halfway subconciously applying meticulous scoping?
- mar77i 8y ago
  There's an actual difference in behavior between`read name` and `read`: one strips leading and trailing whitespace, the other does not. I know it because I once needed to strip whitespace and only found out through IRC; the difference is only somewhat hinted at in the manual.
  - teddyh 8y ago
    In the case where you want to preserve whitespace, you probably want to do this, then: read -r foo="$REPLY"
- noisy_boy 7y ago
  Yeah I don't use it in practice - I remembered it because it was part of my bash trivia collection when I started learning more about shell scripts many years go. Named variables are obviously a cleaner choice.
avar 8y ago
Why do you find $PIPESTATUS useful? It is in theory, but in practice I've never found a situation where I wouldn't just want to fail the whole pipe if one part of it failed, which is what "set -o pipefail" is for. It's good practice to start your scripts with "set -euo pipefail" and then list exceptions to that scoped with "set +..." as needed. That's the "unofficial bash strict mode"[1]. I don't use the IFS recommendation in that article. I prefer to just keep one set of shell inanities in my head, and being used to the non-default IFS behavior doesn't help when debugging other people's shellscripts. 1. http://redsymbol.net/articles/unofficial-bash-strict-mode/ http://redsymbol.net/articles/unofficial-bash-strict-mode/
- noisy_boy 7y ago
  Because sometimes you want to take some action in case of non-zero $PIPESTATUS instead of just failing everything immediately. This provides full control.

teddyh 8y ago

I would recommend against using $REPLY, for two related reasons: 1. It’s confusing to do a plain “read” and later have a magic $REPLY variable show up, seemingly from nowhere. It has shades of Perl, and I mean nothing positive with that statement. 2. Names are good. By setting a name to the thing which is read, you make the later code easier to read. It’s easier to understand “echo $filename” than “echo $REPLY”, so if you’re reading filenames, do “read filename”. (Or, rather, you probably want to do “read -r filename”, but that’s a different subject.)

daveFNbuck 8y ago
I don't do a lot of bash programming, but I imagine using $REPLY also increases the danger of having the value overwritten before you use it as your code changes.
- mar77i 8y ago
  Now that you mentioned it, I never hit the case where I would read two different times in the same function/subshell scope and would never have considered this a problem. But maybe I'm just preempting this halfway subconciously applying meticulous scoping?
mar77i 8y ago
There's an actual difference in behavior between`read name` and `read`: one strips leading and trailing whitespace, the other does not. I know it because I once needed to strip whitespace and only found out through IRC; the difference is only somewhat hinted at in the manual.
- teddyh 8y ago
  In the case where you want to preserve whitespace, you probably want to do this, then: read -r foo="$REPLY"
noisy_boy 7y ago
Yeah I don't use it in practice - I remembered it because it was part of my bash trivia collection when I started learning more about shell scripts many years go. Named variables are obviously a cleaner choice.

avar 8y ago

Why do you find $PIPESTATUS useful? It is in theory, but in practice I've never found a situation where I wouldn't just want to fail the whole pipe if one part of it failed, which is what "set -o pipefail" is for. It's good practice to start your scripts with "set -euo pipefail" and then list exceptions to that scoped with "set +..." as needed. That's the "unofficial bash strict mode"[1]. I don't use the IFS recommendation in that article. I prefer to just keep one set of shell inanities in my head, and being used to the non-default IFS behavior doesn't help when debugging other people's shellscripts. 1. http://redsymbol.net/articles/unofficial-bash-strict-mode/ http://redsymbol.net/articles/unofficial-bash-strict-mode/

noisy_boy 7y ago
Because sometimes you want to take some action in case of non-zero $PIPESTATUS instead of just failing everything immediately. This provides full control.