3 ms·

FWIW, I can assure you I did not deliberately walk into minefields while developing my recent bash project, and yet I've struggled with `errexit` and `errtrace`

by mietek 12y ago

FWIW, I can assure you I did not deliberately walk into minefields while developing my recent bash project, and yet I've struggled with `errexit` and `errtrace` to the point where I've ceased to use them, preferring to just ` || die` everything which may possibly fail. Although you may say that simply choosing to use bash is self-defeating already... Have you reviewed the examples on this page, linked from the FAQ? http://fvue.nl/wiki/Bash:_Error_handling http://fvue.nl/wiki/Bash:_Error_handling

mturmon 12y ago
Respectfully, this is nuts. You consider it a problem with 'set -e' that, if someone runs your script via % bash foo.sh then a '-e' on the shebang line of foo.sh will be ignored. That's a more general issue, separate from -e. You can say users who do that deserve what they get (not unreasonable IMHO), or you can use a 'set -e' within the script. But don't say it's a problem with -e. It's actually a problem with running command interpreters on arbitrary files. I can't read any more of these examples. I think you need more experience with shell, or maybe we have incommensurate approaches/expectations. I'm not of the view that using bash/sh in itself is a bad choice. There are lots of problems that it's well-suited for, and I myself use sh scripts a lot (with a linear flow that can go on for hundreds of lines). In particular, I don't think python is a good replacement for my use cases.
- mietek 12y ago
  What are you talking about? Are you reading the same page as me? Let me quote http://fvue.nl/wiki/Bash:_Error_handling http://fvue.nl/wiki/Bash:_Error_handling Caveat 1: #!/bin/bash -e echo begin (false) echo end Executing the script above gives: $ ./caveat1.sh begin end $ This has nothing to do with "ignoring the '-e' on the shebang line." This is bash ignoring the exit status of the explicit subshell, even though `errexit` is set.
- mturmon 12y ago
  Sorry, my impatience led me to misread the page.

by mietek 12y ago

mturmon 12y ago

Respectfully, this is nuts. You consider it a problem with 'set -e' that, if someone runs your script via % bash foo.sh then a '-e' on the shebang line of foo.sh will be ignored. That's a more general issue, separate from -e. You can say users who do that deserve what they get (not unreasonable IMHO), or you can use a 'set -e' within the script. But don't say it's a problem with -e. It's actually a problem with running command interpreters on arbitrary files. I can't read any more of these examples. I think you need more experience with shell, or maybe we have incommensurate approaches/expectations. I'm not of the view that using bash/sh in itself is a bad choice. There are lots of problems that it's well-suited for, and I myself use sh scripts a lot (with a linear flow that can go on for hundreds of lines). In particular, I don't think python is a good replacement for my use cases.

mietek 12y ago
What are you talking about? Are you reading the same page as me? Let me quote http://fvue.nl/wiki/Bash:_Error_handling http://fvue.nl/wiki/Bash:_Error_handling Caveat 1: #!/bin/bash -e echo begin (false) echo end Executing the script above gives: $ ./caveat1.sh begin end $ This has nothing to do with "ignoring the '-e' on the shebang line." This is bash ignoring the exit status of the explicit subshell, even though `errexit` is set.
mturmon 12y ago
Sorry, my impatience led me to misread the page.