help-bash
[Top][All Lists]
Advanced

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

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


From: Greg Wooledge
Subject: Re: [Help-bash] Evaluations of backticks in if statements
Date: Thu, 23 Feb 2017 12:23:38 -0500
User-agent: Mutt/1.4.2.3i

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.

imadev:~$ `false`
imadev:~$ echo $?
1

imadev:~$ if ; then echo "yes"; else echo "no"; fi
bash: syntax error near unexpected token `;'

imadev:~$ if ""; then echo "yes"; else echo "no"; fi
bash: : command not found
no

imadev:~$ foo=; if $foo; then echo "yes"; else echo "no"; 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.

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.



reply via email to

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