5 ms·
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 [ g
by cduzz 3y ago
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]
- cduzz 3y agoJoke'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]
- tpoacher 3y agolargely 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.
- deleted 3y ago[deleted]
- chatmasta 3y agoHello 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.
- js2 3y agoHello 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).
- chatmasta 3y agoYeah 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 }
- cduzz 3y agoI 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)
- quicklime 3y agoThe 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-tests 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.
- tuyiown 3y agoReading the comments here it looks like there are somehow dozens of us using test only. Dozens !