4 ms·

Don't use that. If anything, use properly quoted variables: [ -z "$var" ] This has literally no possibility of failing in any weird way, no matter which Bou

by dozzie 10y ago

Don't use that. If anything, use properly quoted variables: [ -z "$var" ] This has literally no possibility of failing in any weird way, no matter which Bourne or Korn shell descendant you use.

ausjke 10y ago
in nearly all cases, you should always do "$var" instead of $var, this should be mandated on sh scripts. you can even go further to do "${bar}", this is even safer I feel.
- scurvy 10y ago
  Yes, it's "${bar}" that should go into style guides and linters (for consistency).
  - brazzledazzle 10y ago
    It seems kind of petty I guess but that seems kind of annoying to write and even less importantly looks pretty blah.
- dozzie 10y ago
  "${bar}" is irritating to write. It only makes sense when you need to append a word character ([a-zA-Z0-9_]) to the content of $bar, like in "${bar}qq".
  - philipov 10y ago
    "${bar}" makes my syntax highlighting light up in a satisfying way, and automatic quote/brace completion makes it peachy.
SubiculumCode 10y ago
Have something against [[ ]] ?
- dozzie 10y ago
  Of course I have. [[ ]] is shell-specific, which for scripts almost always means bash-specific, and bash has a history of subtly changing semantics of such constructs. I've seen scripts suddenly stop working for no apparent reason, only to discover later that bash upgrade changed how [[ == ]] treated unanchored patterns (or something of similar caliber). And now go figure where the bug is. Most of the time, whatever is in [[ ]] can be easily emulated with POSIX/SUS-compatible tools and most of the time it doesn't matter that the tool is not a shell built-in.
  - pyre 10y ago
    [[ ]] works in bash, zsh, and (iirc) ksh. Saying it's "bash-specific" isn't accurate.
    - dozzie 10y ago
      Depends on what you mean by "works". Yes, all three shells recognize [[ ]] construct, as it was specifically added to SUS (or POSIX?) for implementation-specific things, but how they interpret it is up to the specific shell. Let's take people's favourite =~ operator. In bash, according to documentation, it uses ERE syntax. In zsh, it is ERE or PCRE, depending on an option being set. This is a subtle but important difference in how [[ ]] works. And then again, your environment can change the behaviour of a script you're running, which is (a) unexpected and (b) undesirable, and the change in the behaviour can range from "doesn't find thing it should" to "crashes" to "goes awry in an unexpected way".
brobinson 10y ago
It fails with "set -u" enabled :-) [ -z "${var-}" ] works with +u or -u

by dozzie 10y ago

Don't use that. If anything, use properly quoted variables: [ -z "$var" ] This has literally no possibility of failing in any weird way, no matter which Bourne or Korn shell descendant you use.

ausjke 10y ago

in nearly all cases, you should always do "$var" instead of $var, this should be mandated on sh scripts. you can even go further to do "${bar}", this is even safer I feel.

scurvy 10y ago
Yes, it's "${bar}" that should go into style guides and linters (for consistency).
- brazzledazzle 10y ago
  It seems kind of petty I guess but that seems kind of annoying to write and even less importantly looks pretty blah.
dozzie 10y ago
"${bar}" is irritating to write. It only makes sense when you need to append a word character ([a-zA-Z0-9_]) to the content of $bar, like in "${bar}qq".
- philipov 10y ago
  "${bar}" makes my syntax highlighting light up in a satisfying way, and automatic quote/brace completion makes it peachy.

SubiculumCode 10y ago

Have something against [[ ]] ?

dozzie 10y ago
Of course I have. [[ ]] is shell-specific, which for scripts almost always means bash-specific, and bash has a history of subtly changing semantics of such constructs. I've seen scripts suddenly stop working for no apparent reason, only to discover later that bash upgrade changed how [[ == ]] treated unanchored patterns (or something of similar caliber). And now go figure where the bug is. Most of the time, whatever is in [[ ]] can be easily emulated with POSIX/SUS-compatible tools and most of the time it doesn't matter that the tool is not a shell built-in.
- pyre 10y ago
  [[ ]] works in bash, zsh, and (iirc) ksh. Saying it's "bash-specific" isn't accurate.
  - dozzie 10y ago
    Depends on what you mean by "works". Yes, all three shells recognize [[ ]] construct, as it was specifically added to SUS (or POSIX?) for implementation-specific things, but how they interpret it is up to the specific shell. Let's take people's favourite =~ operator. In bash, according to documentation, it uses ERE syntax. In zsh, it is ERE or PCRE, depending on an option being set. This is a subtle but important difference in how [[ ]] works. And then again, your environment can change the behaviour of a script you're running, which is (a) unexpected and (b) undesirable, and the change in the behaviour can range from "doesn't find thing it should" to "crashes" to "goes awry in an unexpected way".

brobinson 10y ago

It fails with "set -u" enabled :-) [ -z "${var-}" ] works with +u or -u