4 ms·

How about just writing safe code. Really... Check your damn return values. set -e is a crutch of a sloppy programmer. Ok, yes; you can do this really slick

How about just writing safe code. Really... Check your damn return values. set -e is a crutch of a sloppy programmer. Ok, yes; you can do this really slick thing in one line by stringing together a bunch of commands. However, just because you can does not mean you should. Bash makes it simply with 'if ! <command>; then <failure commands> fi'. Try not to string ten things together. Keep conditional true state in your scripts execution flow.

jstimpfle 9y ago
That means that you have to write everything to temporary files first. If you want to do that then maybe Python is already more convenient.
- marcosdumay 9y ago
  If you are doing anything with complex behavior that requires error checking, interpolating strings with possibly invalid values, or just writing a lot of code, then Python is already more convenient and if you didn't notice it is because you are hiding a lot of Bash problems under a carpet.
  - jstimpfle 9y ago
    That's my point. It's not easy and often impossible to write robust shell scripts. Part of it is the problem domain. Rewriting any slightly complex bash script in e.g. Python with robust error handling can be quite challenging. You have to make a number of very difficult decisions.
- kps 9y ago
  > That means that you have to write everything to temporary files first. Using the example from the post, echo "($(ldap-query-for-valid-users))" > "/tmp/all-users.sexp" you have at least a couple alternatives to an additional temporary file. if ! valid__users=$(ldap-query-for-valid-users) then ... failure case ... fi echo "($valid__users)" >/tmp/all-users.sexp or { echo -n '(' if ! ldap-query-for-valid-users then ... failure case ... fi echo ')' } >/tmp/all-users.sexp
  - jstimpfle 9y ago
    As an aside, command substitution can't handle binary, and it strips all trailing newlines.
  - btilly 9y ago
    And when multiple bash scripts do that, it is easy to have them accidentally overwrite each other's temp files. Plus an attacker can play with temp files in a number of interesting ways to turn their use into an attack.
    - kps 9y ago
      I was just illustrating the error checking using commands functionally equivalent to the original post. Temporary files are best avoided entirely unless some command actually requires a seekable file, in which case use mktemp(1) or equivalent (and 'trap 0' to clean up after yourself).
andreyv 9y ago
If you need to replace every single <command> with "if ! <command>; then <failure commands>; fi": - How readable will your script be? - How likely are you to miss a few checks? - Will you be careful enough to also check commands like "echo" and "rm"? "set -e" makes error handling implicit instead of explicit, and it solves these problems.
moosingin3space 9y ago
> How about just writing safe code This is a bad argument -- our tools shouldn't make the "easy path" a path that's littered with subtle bugs! It should be easy to do the right thing. See: PHP hand-coded apps that led to SQL injection often versus Python's DBAPI which makes it harder to make mistakes, Signal versus some PGP GUI, etc. People make mistakes when their tools make it easy for them to do the wrong thing. I have the same complaint against much of the standard C library too, but for a language that the user interacts with on a daily basis, this is unacceptable.

jstimpfle 9y ago

That means that you have to write everything to temporary files first. If you want to do that then maybe Python is already more convenient.

marcosdumay 9y ago
If you are doing anything with complex behavior that requires error checking, interpolating strings with possibly invalid values, or just writing a lot of code, then Python is already more convenient and if you didn't notice it is because you are hiding a lot of Bash problems under a carpet.
- jstimpfle 9y ago
  That's my point. It's not easy and often impossible to write robust shell scripts. Part of it is the problem domain. Rewriting any slightly complex bash script in e.g. Python with robust error handling can be quite challenging. You have to make a number of very difficult decisions.
kps 9y ago
> That means that you have to write everything to temporary files first. Using the example from the post, echo "($(ldap-query-for-valid-users))" > "/tmp/all-users.sexp" you have at least a couple alternatives to an additional temporary file. if ! valid__users=$(ldap-query-for-valid-users) then ... failure case ... fi echo "($valid__users)" >/tmp/all-users.sexp or { echo -n '(' if ! ldap-query-for-valid-users then ... failure case ... fi echo ')' } >/tmp/all-users.sexp
- jstimpfle 9y ago
  As an aside, command substitution can't handle binary, and it strips all trailing newlines.
- btilly 9y ago
  And when multiple bash scripts do that, it is easy to have them accidentally overwrite each other's temp files. Plus an attacker can play with temp files in a number of interesting ways to turn their use into an attack.
  - kps 9y ago
    I was just illustrating the error checking using commands functionally equivalent to the original post. Temporary files are best avoided entirely unless some command actually requires a seekable file, in which case use mktemp(1) or equivalent (and 'trap 0' to clean up after yourself).

andreyv 9y ago

If you need to replace every single <command> with "if ! <command>; then <failure commands>; fi": - How readable will your script be? - How likely are you to miss a few checks? - Will you be careful enough to also check commands like "echo" and "rm"? "set -e" makes error handling implicit instead of explicit, and it solves these problems.

moosingin3space 9y ago

> How about just writing safe code This is a bad argument -- our tools shouldn't make the "easy path" a path that's littered with subtle bugs! It should be easy to do the right thing. See: PHP hand-coded apps that led to SQL injection often versus Python's DBAPI which makes it harder to make mistakes, Signal versus some PGP GUI, etc. People make mistakes when their tools make it easy for them to do the wrong thing. I have the same complaint against much of the standard C library too, but for a language that the user interacts with on a daily basis, this is unacceptable.