3 ms·
indeed you are right. Thanks for the reply. I'm too accustomed to seeing code like: if [ $? -eq 0 ]; then echo "pass";else echo "fail";fi But without the
by gricardo99 6y ago
indeed you are right. Thanks for the reply.
I'm too accustomed to seeing code like:
if [ $? -eq 0 ]; then echo "pass";else echo "fail";fi
But without the expression '[ ... ]' shell/bash does indeed treat zero return code (success) as boolean true.
For whatever reason I have not seen much (if any) bash code that simply uses:
if COMMAND; then ...
- fl0wenol 6y agoYou really really should use if COMMAND logic, in the event that all you care about is zero or non-zero result. I find it easier to follow for shell control flow. It also works for shell functions.
- dllthomas 6y agoFrom one perspective, if [ $? -eq 0 ]; then ... is actually an instance of if COMMAND; then ... because [ is itself a command.
- gricardo99 6y agoyep, I think that's the key point I need to drill into my head. The unix/linux idiom where 0 is true/success and non-zero is a failure can be counter-intuitive when combined with "if" (at least for me, hence my mistake reading the code). In most/other computing contexts "if 0" is never taken. I think this might explain why I've seen a lot more bash code that is explicitly written in the form more familiar to "if" usage in other languages (pseudo-code): "if res == 0". But "if COMMAND" is taking care of the interpretation of the return code, so doing the explicit compare is redundant.