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

[Seth David Schoen]

Andy Chu writes:

> Shell doesn't work this way.  The syntax is "if command", and
> 
> if `command`
> 
> is a particular case of that which is not special in any way (and as you
> mention it's also not useful).  There's no such thing as
> 
> if ""
> 
> where "" is a string/variable value -- the "" is interpreted a command name.

I agree with this interpretation, but I see behavior that I don't know
how to account for.  Presumably the shell should be running the output
of the substituted command and then checking the return code of _that_,
which accounts for

$ if `echo true`; then echo foo; fi
foo
$ if `echo false`; then echo foo; fi
$ 

And it also accounts for

$ if `echo wow`; then echo foo; fi
wow: command not found

But since neither true(1) nor false(1) outputs anything, there shouldn't
be a difference between

$ if `true`; then echo foo; fi
foo
$ if `false`; then echo foo; fi
$

and indeed both of them should presumably complain about the unknown
command with an empty name -- but neither does, and they exhibit
different behavior from one another.  So is there a special case after
all?  I can't find a justification for this in the man page's
documentation of "if" or command substitution.

-- 
Seth David Schoen <address@hidden>      |  No haiku patents
     http://www.loyalty.org/~schoen/        |  means I've no incentive to
  8F08B027A5DB06ECF993B4660FD4F0CD2B11D2F9  |        -- Don Marti