Comment by cduzz | Hacker News Reader

Comment by cduzz | Hacker News Reader

I have strong opinions about shell and they don't actually line up with the rest of the world...

I believe that [ should never be used, only "test" because [ gives the illusion that the mechanism is some part of the language syntax when it is just another "program" (I'm including built-ins and functions in "program").

(if / || / && look at exit status; a program can't see the exit status of other things other than looking at the magic variable $? which is just another string once expanded; case looks at strings but doesn't operate based on exit status and doesn't set an exit status as part of the case ... esac operation; "programs" set an exit status)

I also believe that [ / test should only ever be used for evaluating filesystem constructs -- test -f /dev/null and if you've got string evaluations use case.

Unsurprisingly, most scripts make me itchy, and scripts that I write people find weird.

[edited to add the explanation of "program" vs "syntax" opinion]

Joke's on me; that's the point of the article.

I prefer, when writing in shell, to do this:

    if 
      program
    then
      something
    else
      otherthing
    fi

To emphasize that the thing after the if is just "look at the exit status of the last command before the then."

    if
      ls /tmp/goober
      test -d /tmp/goober
      echo "I'll always execute the then clause because echo will always return a 0 return code"
    then
      echo "this always gets run"
    else
      echo "this never gets run"
    fi

because the "if" is just looking at the exit status of "echo".

[edited to do code blocks]

largely agree, but stylistically speaking I prefer the following:

  if   ls /tmp/goober
       test -d /tmp/goober
       echo "I'll always love you or whatever"
  then echo "the grasshopper always jumps higher"
  else "never gonna let you down"
  fi

i.e. all the commands line up at the 6th column, leaving the if/then/elif/else/fi stuff appearing on the 'margin', as it were.

This works particularly well, visually, when nested ifs are involved.

Hello fellow traveler. I've got 8 years of scripts with `test` in them to prove I agree with you. It's a lonely road out there... I blame the Google shell style guide.

I picked up the habit of preferring `test` when I was writing scripts that needed to run in both `sh` and `bash`, but I kept it because it makes more semantic sense to me than treating a character like `[` as a command. It's also weird that `]` is an argument to `[` rather than also being a binary. I mean, I understand the technical reasoning... but it feels like a hack.

Hello fellow traveler. I've got 20 years of scripts with `if test` in them. I only use `[[` when I need functionality it provides that `test` does not (pattern or regex matching, typically, and for pattern matching I'll generally use a case statement instead).

Yeah that's when I use it too. I figure if I've already given into the temptations of Bash, I may as well go all the way. Sometimes if I'm feeling extra frisky I even do [[ .. ]] || { echo "error!" ; exit 1 }

I imagine most people have sets of macros they habitually add to any sufficiently complex script they're modifying...

  yelp(){
    es=$1
    shift
    echo "$@" >&2
    exit $es
  }
  
  test -d /tmp/goober || yelp 33 "couldn't find goober!"

(yes, I'm sure there are standards for exit status ranges and 33 is not such a thing)

The Google style guide doesn’t disagree with you, it says to code exclusively for bash where possible (ie mostly everywhere inside Google) and to prefer [[ over [ and test:

https://google.github.io/styleguide/shellguide.html#s6.3-tes...

In a scenario where you also need to support shells other than bash, Google’s shell style guide doesn’t say to use [ over test.

Reading the comments here it looks like there are somehow dozens of us using test only. Dozens !

Reply on news.ycombinator.com