Re: [Help-bash] Evaluations of backticks in if statements

[Eric Blake]

On 02/23/2017 11:23 AM, Greg Wooledge wrote:

> Right, so.  Apparently bash treats a command substitution that returns an
> empty string in some special-snowflake way, rather than as a syntax error.

> 
> imadev:~$ foo=; if $foo; then echo "yes"; else echo "no"; fi
> yes
> 

and:

$ set -; if "$@"; then echo yes; fi
yes

> 
> So yes, somehow apparently a command substitution (or unquoted variable
> substitution) that returns an empty string is treated differently from
> *nothing* (syntax error), or an actual attempt to execute an empty string
> (command not found).
> 
> I assume there is some POSIX justification for this, blah blah blah.

Yes, POSIX requires that if 0 words result after expansion (whether
unquoted variable expansion, quoted "$@" expansion, or command
substitution), then $? is set to 0 as the successful "execution" of that
empty command.  For the same reason that:

$ eval ''; echo $?
0
$ . /dev/null; echo $?
0

> 
> Point is, it's crap.  Stop doing it.  Chet has to worry about making
> bash handle all of this crap in exactly the right way that POSIX
> dictates.  You, as a script writer, do not need to worry about this.
> Just don't do it.  Problem solved.

Agreed :)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature