[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chet Ramey
Subject: Re: [Help-bash] Evaluations of backticks in if statements
Date: Thu, 23 Feb 2017 14:06:21 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1

On 2/23/17 12:23 PM, Greg Wooledge wrote:
> On Thu, Feb 23, 2017 at 09:10:52AM -0800, Seth David Schoen wrote:
>> $ if `true`; then echo foo; fi
>> foo
>> $ if `false`; then echo foo; fi
>> $
> First of all, and I cannot possibly stress this enough, this is shitty
> code and you should never EVER write code like this.
> Right, so.  Apparently bash treats a command substitution that returns an
> empty string in some special-snowflake way, rather than as a syntax error.

Please. Don't overthink this.

First, why should bash treat a command substitution that returns no output
as anything different from a variable expansion that has no value?

Consider `something`.  That's a simple command, with a single word, that
undergoes word expansion.  It can either expand to some text, in which
case that text undergoes word splitting and globbing and is executed as a
command, or nothing.

If it returns nothing, it falls into this Posix-standardized and historical
shell behavior category:

"If there is no command name, but the command contained a command
substitution, the command shall complete with the exit status of the last
command substitution performed."

Virtually the same language appears in the bash manual.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]