6 ms·

or check the variable before using it, like any other programming language: [[ "$VAR" ]] && rm -rf "$VAR/*" I think most of these issues stem from the fact th

or check the variable before using it, like any other programming language: [[ "$VAR" ]] && rm -rf "$VAR/*" I think most of these issues stem from the fact that most developers that write shell scripts don't actually understand what they're doing, treating the script as a necessary annoyance rather than a component of the software.

TheDong 11y ago
If anyone understands shell scripts, it would be people writing init scripts at Red Hat :) Anyways, that is not anything like other programming languages. Checking in that way is error prone and not really an improvement (nor equivalent to set -o). [[ "$DAEMON_PATH" ]] && rm -rf "$DEAMON_PATH/*" See what I did there? It's an rm -rf /* bug because "checking variables" is not the answer. In other programming languages, if an identifier is mis-typed things will blow up. E.g., in ruby if I write: daemon_path=1; if daemon_path; puts deamon_path; end I get "NameError: undefined local variable or method `deamon_path`" These issues do not always stem from bad developers. Bash's defaults are not safe in many ways and saying "people should just check the variable" isn't helpful here.
- bishc 11y ago
  Shameless plug for my language "bish" (compiles to bash) which aims to solve many of these annoyances with shell scripting: https://github.com/tdenniston/bish https://github.com/tdenniston/bish
- pwg 11y ago
  Bash has the ability to also flag use of an undefined variable an error, it is just not on by default. set -u Man page quote: "Treat unset variables and parameters other than the special parameters "@" and "*" as an error when performing parameter expansion. If expansion is attempted on an unset variable or parameter, the shell prints an error message, and, if not interactive, exits with a non-zero status."
mraison 11y ago
> like any other programming language some real-world programming languages don't have undefined variables :)
- coldtea 11y ago
  Since the variable he shows is used in a string interpolation, it doesn't have to be undefined. Being the emptys string "" would work just as well.
woah 11y ago
Elephant in the room- shell is a bizarre language
- Someone1234 11y ago
  Yeah, everyone always loves to shit on BAT (which is fair, it is terrible) and VBS (which is slightly less fair) but inspite of how many problems Bash has (least of all the massive security issue last year), it gets off almost scot free. These bugs are indicative of Bash's design problems. Why is it used for init scripts? And don't even get me started on how Bash interprets filenames as part of the arguments list when using * (e.g. file named "-rf"). Say what you will about Powershell, but having a typed language that can throw a null exception is useful for bugs like these. The filename isn't relevant, and a null name on a delete won't try to clear out of the OS (just throw).
  - sjolsen 11y ago
    >And don't even get me started on how Bash interprets filenames as part of the arguments list when using * (e.g. file named "-rf") That's not Bash. That's just... programs in Unix. Such is life when everything is stringly typed.
  - rodgerd 11y ago
    > it gets off almost scot free. Not just scot free - during the Great systemd War of 2014 is was a talking point for the antis that using anything other than the pure, reliable simplicity of shell for service management was MADNESS!
    - digi_owl 11y ago
      I don't think that was the argument, as much as it was that if a shell script fouled up it was easier to get in and do field repairs because it was interpreted rather than compiled.
emmelaich 11y ago
I think a better alternative is something like rm -r "${VAR:-var_is_not_set_so_please_fix_this_script}" which substitutes the var_is_... if VAR is not set. BTW, I hate hate hate -f. It has two meanings: 1. 'force' the removal 2. ignore any error I've seen an instance of this sort of bug in my sysadmin career that I remember. It was a Solaris patch which wiped a chunk of the system.
- rjcz 11y ago
  No, this will remove 'var_is_not_set_so_please_fix_this_script' file if one exists. If you're suggesting using parameter expansion, at least suggest the correct one (i.e. one that will give a meaningful error message): ${parameter:?word} http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...
  - emmelaich 11y ago
    Yep, better. Thanks.

TheDong 11y ago

If anyone understands shell scripts, it would be people writing init scripts at Red Hat :) Anyways, that is not anything like other programming languages. Checking in that way is error prone and not really an improvement (nor equivalent to set -o). [[ "$DAEMON_PATH" ]] && rm -rf "$DEAMON_PATH/*" See what I did there? It's an rm -rf /* bug because "checking variables" is not the answer. In other programming languages, if an identifier is mis-typed things will blow up. E.g., in ruby if I write: daemon_path=1; if daemon_path; puts deamon_path; end I get "NameError: undefined local variable or method `deamon_path`" These issues do not always stem from bad developers. Bash's defaults are not safe in many ways and saying "people should just check the variable" isn't helpful here.

bishc 11y ago
Shameless plug for my language "bish" (compiles to bash) which aims to solve many of these annoyances with shell scripting: https://github.com/tdenniston/bish https://github.com/tdenniston/bish
pwg 11y ago
Bash has the ability to also flag use of an undefined variable an error, it is just not on by default. set -u Man page quote: "Treat unset variables and parameters other than the special parameters "@" and "*" as an error when performing parameter expansion. If expansion is attempted on an unset variable or parameter, the shell prints an error message, and, if not interactive, exits with a non-zero status."

mraison 11y ago

> like any other programming language some real-world programming languages don't have undefined variables :)

coldtea 11y ago
Since the variable he shows is used in a string interpolation, it doesn't have to be undefined. Being the emptys string "" would work just as well.

woah 11y ago

Elephant in the room- shell is a bizarre language

Someone1234 11y ago
Yeah, everyone always loves to shit on BAT (which is fair, it is terrible) and VBS (which is slightly less fair) but inspite of how many problems Bash has (least of all the massive security issue last year), it gets off almost scot free. These bugs are indicative of Bash's design problems. Why is it used for init scripts? And don't even get me started on how Bash interprets filenames as part of the arguments list when using * (e.g. file named "-rf"). Say what you will about Powershell, but having a typed language that can throw a null exception is useful for bugs like these. The filename isn't relevant, and a null name on a delete won't try to clear out of the OS (just throw).
- sjolsen 11y ago
  >And don't even get me started on how Bash interprets filenames as part of the arguments list when using * (e.g. file named "-rf") That's not Bash. That's just... programs in Unix. Such is life when everything is stringly typed.
- rodgerd 11y ago
  > it gets off almost scot free. Not just scot free - during the Great systemd War of 2014 is was a talking point for the antis that using anything other than the pure, reliable simplicity of shell for service management was MADNESS!
  - digi_owl 11y ago
    I don't think that was the argument, as much as it was that if a shell script fouled up it was easier to get in and do field repairs because it was interpreted rather than compiled.

emmelaich 11y ago

I think a better alternative is something like rm -r "${VAR:-var_is_not_set_so_please_fix_this_script}" which substitutes the var_is_... if VAR is not set. BTW, I hate hate hate -f. It has two meanings: 1. 'force' the removal 2. ignore any error I've seen an instance of this sort of bug in my sysadmin career that I remember. It was a Solaris patch which wiped a chunk of the system.

rjcz 11y ago
No, this will remove 'var_is_not_set_so_please_fix_this_script' file if one exists. If you're suggesting using parameter expansion, at least suggest the correct one (i.e. one that will give a meaningful error message): ${parameter:?word} http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...
- emmelaich 11y ago
  Yep, better. Thanks.