Empty variable is treated as logical "true" with `$var && action` (shell parsing)

Question

Consider a simple debugging style where $debug would be set either to true or false according to some command-line flag:

$debug && echo "Something strange just happened" >&2

I know there are better ways to protect against value setting, such as ${debug:-false} or even a full-featured logMessage()-type function, but let's park that for now.

Assume the bad situation where $debug remains unset or empty. I expected that $debug && echo … for such an empty $debug would be parsed and evaluated into && echo …, which would trigger a consequent syntax error. But instead it seems to be evaluated into something like : && echo …, which ends up executing the echo.

I've tested with bash, ksh, and dash and the scenario remains consistent.

My understanding was that these two lines parsed out as equivalent, but clearly they do not:

unset debug; $debug && echo stuff
unset debug; && echo stuff

Why does the code act as if an unset variable is logically true instead of failing with an error such as syntax error near unexpected token `&&'?

Answer 1

But syntax isn't checked after the expansion is done.

$foo is a syntactically valid simple command regardless of the value the variable has and the number of fields produced after the expansion. It's one shell "word" before expansions, and that's enough.

Having $foo && whatever be equal to && whatever would be similar to expecting the shell to parse the results of the expansion for other syntax too, keywords, quotes, whatever. That's not done.

Hence:

foo="then if"
$foo

is not a syntax error, but tries to run a regular command called then _{(which probably doesn't exist and you get an error, but it could exist, and the "command not found" error is a different one from the syntax error from trying to run then if all by itself.)}.

And:

foo=
$foo

is not a syntax error, but tries to run a... well, it doesn't because there's no "command name", and while that's a sort of a special case, it's not an error. See 2.9.1 Simple Commands:

When a given simple command is required to be executed, the following expansions, assignments, and redirections shall all be performed from the beginning of the command text to the end:

1. [assignments, redirections]

2. The words that are not variable assignments or redirections shall be expanded. If any fields remain following their expansion, the first field shall be considered the command name and remaining fields are the arguments for the command. [...]

Note the "if".

What results without a command name is that variable assignments affect the current execution environment, and if there is no command substitution either, then the exit status is zero.

So if $foo is empty or unset:

$foo

just does nothing and sets the exit status to zero, and

bar=asdf $foo

sets $bar to asdf and the exit status to zero. The same as just bar=asdf, but if $foo did expand to a command name, the assignment would only apply for the command.

Answer 2

From the Shell Command Language specification, section 2.9.1 Simple Commands, after all the redirections, glob/parameter expansions, etc. are performed:

If there is a command name, execution shall continue as described in Command Search and Execution. 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. Otherwise, the command shall complete with a zero exit status.

You're in the "otherwise" case.

Answer 3

A simple command consists of assignments, redirections and arguments (the first of which used to derive the command to run).

All are optional. If there's no arguments, the command succeeds as long as all the redirections can be performed and the last run command substitution in the target of redirections and assignments (or the ones used to generate an empty list of arguments) succeeds, though IIRC, it's unspecified which of the redirections and assignments are done first.

All those succeed:

• a=whatever: no command, no redirection, only assignment
• $(true): no command, no redirection, no assignment, successful command substitution that results in an empty list.
• a=$(false) b=$(true). Only assignment, the last command substitution succeeds.
• > /dev/null: no command, successful redirection
• > "$(echo /dev/null)": no command, successful command substitution and redirection
• empty=; a=foo $empty > /dev/null: assignments and redirections, and an expansion that results in an empty list, so no argument/command.
• empty=; $empty: same as above without assignment nor redirection.

These fail:

• false
• a=$(false)
• $(false)
• > /etc/passwd/foo
• < /dev/null"$(false)"
• ...

Unspecified:

• $(true) > /dev/null$(false)
• a=$(false) > /dev/null$(true)

Answer 4

Consider that && is an operator that joins 2 lists of commands pipelines (3.2.4 Lists of Commands).

The first command is $debug. If the variable is unset, there is no command -- it's just like hitting Enter at a prompt: no command is executed but also no non-zero exit status.

Since there was no error on the left-hand side of &&, the right-hand side is free to run.

Quoting will give you the error you seek

• bash

  $ unset debug; $debug && echo hmm
  hmm
  $ unset debug; "$debug" && echo hmm
  bash: : command not found
  

• ksh

  $ unset debug; $debug && echo hmm
  hmm
  $ unset debug; "$debug" && echo hmm
  ksh: : cannot execute [Is a directory]
  

• dash

  $ unset debug; $debug && echo hmm
  hmm
  $ unset debug; "$debug" && echo hmm
  dash: 9: : Permission denied