Bash – Quoting Within $(command substitution)

bashcommand-substitutionquotingshell

In my Bash environment I use variables containing spaces, and I use these variables within command substitution.

What is the correct way to quote my variables? And how should I do it if these are nested?

DIRNAME=$(dirname "$FILE")

or do I quote outside the substitution?

DIRNAME="$(dirname $FILE)"

or both?

DIRNAME="$(dirname "$FILE")"

or do I use back-ticks?

DIRNAME=`dirname "$FILE"`

What is the right way to do this? And how can I easily check if the quotes are set right?

Best Answer

In order from worst to best:

DIRNAME="$(dirname $FILE)" will not do what you want if $FILE contains whitespace (or whatever characters $IFS currently contains) or globbing characters \[?*.
DIRNAME=`dirname "$FILE"` is technically correct, but backticks are not recommended for command expansion because of the extra complexity when nesting them and the extra backslash processing that happens within them.
DIRNAME=$(dirname "$FILE") is correct, but only because this is an assignment to a scalar (not array) variable. If you use the command substitution in any other context, such as export DIRNAME=$(dirname "$FILE") or du $(dirname -- "$FILE"), the lack of quotes will cause trouble if the result of the expansion contain whitespace or globbing characters.
DIRNAME="$(dirname "$FILE")" (except for the missing --, see below) is the recommended way. You can replace DIRNAME= with a command and a space without changing anything else, and dirname receives the correct string.

To improve even further:

DIRNAME="$(dirname -- "$FILE")" works if $FILE starts with a dash.
DIRNAME="$(dirname -- "$FILE" && printf x)" && DIRNAME="${DIRNAME%?x}" || exit works even if $FILE's dirname ends with a newline, since $() chops off newlines at the end of output, both the one added by dirname and the ones that may be part of the actual data.

You can nest command expansions as much as you like. With $() you always create a new quoting context, so you can do things like this:

foo "$(bar "$(baz "$(ban "bla")")")"

You do not want to try that with backticks.

Related Solutions

Shell Environment Variables – Significance of Single and Double Quotes

I think you're confused about terminology.

An "environment variable" is merely a shell variable that any child processes will inherit.

What you're doing in your example is creating a shell variable. It's not in the environment until you export it:

MY_HOME="/home/my_user"
export MY_HOME

puts a variable named "MY_HOME" in almost all shells (csh, tcsh excepted).

In this particular case, the double-quotes are superfluous. They have no effect. Double-quotes group substrings, but allows whatever shell you use to do variable substitution. Single-quoting groups substrings and prevents substitution. Since your example assignment does not have any variables in it, the double-quotes could have appeared as single-quotes.

V='some substrings grouped together'  # assignment
X="Put $V to make a longer string"    # substitution and then assignment
Y=`date`                              # run command, assign its output
Z='Put $V to make a longer string'    # no substition, simple assignment

Nothing is in the environment until you export it.

Bash Scripting – Nested Double Quotes in Command Substitution

Your puzzle isn't right about how bash (and the shell in general) parsed the input. In:

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

First, bash parse the right hand side of assignment to one long string $( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd ) because double quote can appear inside double quotes.

After then, bash start parsing the command substitution. Because all characters following open parenthesis to enclosing parenthesis are used to construct the command inside command substitution, you will get:

cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd

The shell continue parsing that compound command, break it into two parts:

cd "$( dirname "${BASH_SOURCE[0]}" )"
pwd

Then applying the same parsing rule for cd "$( dirname "${BASH_SOURCE[0]}" )", but this time, double quotes are not redundant, but make sense. They prevent field splitting on result of $( dirname "${BASH_SOURCE[0]}" ), and also the expansion of ${BASH_SOURCE[0]} (In contrast with the outer most double quotes, will are not necessary in RHS of variable assignment to prevent split+glob).

This rule apply to command substitution in all POSIX shell. A more details puzzle you can read in Token Recognition section of POSIX spec.

Best Answer

Related Solutions

Shell Environment Variables – Significance of Single and Double Quotes

Bash Scripting – Nested Double Quotes in Command Substitution

Related Question