Shell – How exactly does `if $cmd ; then $cmd ; fi` differ from `$cmd && $cmd`

posixshellshell-script

In an answer to another very good question I made the following assertion:

According to my reading of the POSIX specs, the use of one or the other makes no difference from a parsing standpoint.

POSIX specifies that &&|| lists are compound commands which means that the entire list must be read in and parsed before execution of the constituent simple commands. POSIX also specifies a command shall not be expanded if it follows an ||OR and another command with a 0-exit status. When you consider that a command following an &&|| reserved word can easily be another grouped { command || ( command ; list) ; } makes each branch of the &&|| or list its own compound command.

But POSIX also specifies that each branch of the if...;then...;else...fi construct be its own compound command in this way:

if compound-list
then
    compound-list
[elif compound-list
then
    compound-list] ...
[else
    compound-list]
fi

The if compound-list shall be executed; if its exit status is zero, the then compound-list shall be executed and the command shall complete…

It is this specification that the string following a then... or else... reserved words are compound commands in their own right and not merely simple commands that means the shell's parser must denote them with a command and a delimiter in order to operate correctly.

So basically, then ' ' doesn't work for the same reason:

function()
sh: line 2: syntax error: unexpected end of file

…doesn't – it doesn't make any sense.

I know that…

[ -e doesntexist ] && $((i=1)) ; echo $i

…will short-circuit any side-effects and result in only a \newline as a result of the spec I noted in my answer. The result of…

if [ -e doesntexist ] 
    then $((i=1))
fi
echo $i

…is identical.

But I honestly use if...fi so seldom that I'm unsure if I've misread something and so when I received a comment indicating my interpretation was incorrect and that if I had further questions on the matter I need only ask I deleted the answer in lieu of this question: how have I got it wrong – how do they differ?

Best Answer

Only simple cases can be expressed with && and ||. The if construct is more general. if CONDITION; then FOO; fi is equivalent to CONDITION && FOO (assuming proper usage of braces to delimit a block if necessary), but as soon as there's an else (or elif), this is no longer possible in general.

if CONDITION; then FOO; else BAR; fi

is not equivalent to

CONDITION && FOO || BAR

If CONDITION is true, both constructs execute FOO. If FOO is false, then the if construct skips BAR, whereas the && … || construct executes BAR.

And no, you can't work around this with CONDITION && { FOO; true; } || BAR. This makes the compound command return true if CONDITION is true and FOO is false, whereas if CONDITION; then FOO; else BAR; fi returns false in that case.

That's for the semantic difference. In addition, there's readability: nested uses of && and || very quickly become hard to decipher. I don't recommend using both in the same command, in fact — especially given that the two operators have equal precedence in the shell, whereas they have different precedences in C and most other C-inspired languages (including Perl and Ruby).

Related Solutions

Specific reason why iptables would return an exit code of 3 (instead of 1?) when executed without sufficient privileges

The documentation is incomplete. The code contains the following list of error codes used internally:

enum xtables_exittype {
    OTHER_PROBLEM = 1,
    PARAMETER_PROBLEM,
    VERSION_PROBLEM,
    RESOURCE_PROBLEM,
    XTF_ONLY_ONCE,
    XTF_NO_INVERT,
    XTF_BAD_VALUE,
    XTF_ONE_ACTION,
};

And when it tries to initialize, it does:

if (!*handle)
    xtables_error(VERSION_PROBLEM,
           "can't initialize iptables table `%s': %s",
           *table, iptc_strerror(errno));

xtables_error prints the error message and exits with the given exit code.

The code seems to be deficient, IMHO, in assuming that a failure here is due to a version problem, without checking the errno to see that it's actually EPERM.

POSIX Find Command – Why ‘find -exec cmd {} +’ Needs to End in ‘{} +’

The rationale given in the POSIX specification is:

The "-exec ... {} +" syntax adopted was a result of IEEE PASC Interpretation 1003.2 #210. It should be noted that this is an incompatible change to the ISO/IEC 9899:1999 standard. For example, the following command prints all files with a '-' after their name if they are regular files, and a '+' otherwise:
find / -type f -exec echo {} - ';' -o -exec echo {} + ';'
The change invalidates usage like this. Even though the previous standard stated that this usage would work, in practice many did not support it and the standard developers felt it better to now state that this was not allowable.

PASC Interpretation 1003.2 #210 goes into more detail about the history of -exec … {} +. It existed on several Unix systems before it was adopted by POSIX; the defect report traces it back to SVR4 (where it was largely undocumented). The defect report justifies the incompatible change as having little impact in practice:

Note that the "+" is only treated as special if it immediately follows "{}". This minimises the chances of causing problems with existing uses of "+" as an argument with "-exec".

Although adding support for -exec … {} + would break some conforming applications such as the example above, there are fewer of these than if -exec … {} … + was allowed.

Another reason, perhaps, to restrict {} to be the last argument is ease of implementation. If {} was allowed anywhere in the argument list to -exec, the find program would have to build the command line by copying the static arguments, then the variable part, then another static part. This would make it harder to construct the argument list and to account for the size limit. The difficulty is minimal, but implementers like to cut corners. Supporting multiple substitutable instances of {} (if -exec {} foo + is to work, it can be logically expected that -exec {} foo {} + would as well) would be significantly harder.

Best Answer

Related Solutions

Specific reason why iptables would return an exit code of 3 (instead of 1?) when executed without sufficient privileges

POSIX Find Command – Why ‘find -exec cmd {} +’ Needs to End in ‘{} +’

Related Question