5 ms·

while not as portable, using double brackets - i.e. [[ -z $var ]] can be a bit "safer" in regards to quoted variables. Works in bash and KSH. Edit to add:

while not as portable, using double brackets - i.e. [[ -z $var ]] can be a bit "safer" in regards to quoted variables. Works in bash and KSH. Edit to add: http://stackoverflow.com/questions/669452/is-preferable-over-in-bash-scripts http://stackoverflow.com/questions/669452/is-preferable-over...

hashhar 9y ago
Why isn't it being added to POSIX? What does it take to get something added to POSIX?
- nine_k 9y ago
  A time machine?
  - stonogo 9y ago
    The POSIX standard is under active development.
  - hashhar 9y ago
    POSIX is under active development. The issue I'm concerned about is this text quoted from the 'printf' man-page. > %q ARGUMENT is printed in a format that can be reused as shell > input, escaping non-printable characters with the proposed POSIX > $'' syntax.
dozzie 9y 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 9y 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 9y ago
    Yes, it's "${bar}" that should go into style guides and linters (for consistency).
    - brazzledazzle 9y ago
      It seems kind of petty I guess but that seems kind of annoying to write and even less importantly looks pretty blah.
  - dozzie 9y 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 9y ago
      "${bar}" makes my syntax highlighting light up in a satisfying way, and automatic quote/brace completion makes it peachy.
- SubiculumCode 9y ago
  Have something against [[ ]] ?
  - dozzie 9y 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 9y ago
      [[ ]] works in bash, zsh, and (iirc) ksh. Saying it's "bash-specific" isn't accurate.
      - dozzie 9y 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 9y ago
  It fails with "set -u" enabled :-) [ -z "${var-}" ] works with +u or -u

hashhar 9y ago

Why isn't it being added to POSIX? What does it take to get something added to POSIX?

nine_k 9y ago
A time machine?
- stonogo 9y ago
  The POSIX standard is under active development.
- hashhar 9y ago
  POSIX is under active development. The issue I'm concerned about is this text quoted from the 'printf' man-page. > %q ARGUMENT is printed in a format that can be reused as shell > input, escaping non-printable characters with the proposed POSIX > $'' syntax.

dozzie 9y 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 9y 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 9y ago
  Yes, it's "${bar}" that should go into style guides and linters (for consistency).
  - brazzledazzle 9y ago
    It seems kind of petty I guess but that seems kind of annoying to write and even less importantly looks pretty blah.
- dozzie 9y 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 9y ago
    "${bar}" makes my syntax highlighting light up in a satisfying way, and automatic quote/brace completion makes it peachy.
SubiculumCode 9y ago
Have something against [[ ]] ?
- dozzie 9y 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 9y ago
    [[ ]] works in bash, zsh, and (iirc) ksh. Saying it's "bash-specific" isn't accurate.
    - dozzie 9y 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 9y ago
It fails with "set -u" enabled :-) [ -z "${var-}" ] works with +u or -u