-4

Double quoting command substitution is a good practice. Is it the same for process substitution (<() and >())?

It seems double quotes allow command substitution, but disallow process substitution:

$ echo <(printf "%s" hello)
/dev/fd/63
$ echo "<(printf "%s" hello)"
<(printf %s hello)

What if the result of any process substitution contains whitespaces, or that never happens?

Thanks.

  • Are you asking about $(…), <(…), >(…)? – ctrl-alt-delor Dec 4 '18 at 22:39
  • What do you mean by "It doesn't seem to hurt to double quote process substitutions". Could you give an example of its not hurting? – Michael Homer Dec 4 '18 at 22:48
  • 3
    word splitting is not performed on the process substitution. the filenames produced by it don't contain spaces, but you can easily check by setting IFS the /: bash -c 'IFS=/; x=/dev/fd/1; printf "{%s}\n" <(sleep 10) $x'; only the $x will be split. – mosvy Dec 4 '18 at 23:02
5

Quoting process substitution will inhibit it, as is trivially tested:

$ echo <(echo 123)
/dev/fd/63
$ cat <(echo 123)
123
$ echo "<(echo 123)"
<(echo 123)
$ cat "<(echo 123)"
cat: '<(echo 123)': No such file or directory

It is bizarre to me that you did not make an attempt to do so before asking the question, but it is at least easily verified now that it will not work.

This is no different to what happens when quoting other shell operators; echo "(" is not a syntax error for the same reason, nor does echo "> /dev/sda" cause you any problems.

The documented behaviour is that:

This filename is passed as an argument to the current command as the result of the expansion

As a single argument, the presence or absence of whitespace is not material and word-splitting is not relevant and not performed. It is plausible that on some platform whitespace appeared within the generated path, but it would have no impact.

1

In bash, when a string is enclosed by double quotes, it is interpreted as a literal, EXCEPT when at least one of the following special characters are involved:

$ ` \ ! * @

The syntax for process substitution <(command_list)can't be interpreted inside double quotes. There is no character involved that will be interpreted as anything other than a literal. Double quoting MUST prevent process substitution, because it doesn't allow its syntax to be interpreted.

The syntax for command substitution is:

$(command)
# or
`command`

Both of these start with characters that are special characters within double quotes ($, or back-tics), and, as you know, double quoting does not suppress command substitution.

This is generally a good first rule to consider when you want to predict whether double quoting will suppress some behavior. If the syntax doesn't involve one of those 6 characters, double quoting HAS to suppress it (brace expansion, tilde expansion, process substitution, word splitting on , none of these can occur inside double quoting). Of course, not everything with a syntax that involves one of those six characters occurs within double quotes, but it's a good first rule to consider. This answer and rule is meant to help you make predictions before you've encountered and memorized all the cases. If a syntax can't be interpreted inside double quotes, the behavior can't occur.

  • When do @ and * cause something to happen inside double quotes? – Michael Homer Dec 5 '18 at 4:54
  • They're documented as "special", but I can't think of any examples where they operate on their own (i.e., without a preceding $). The documentation for double quotes and shell parameter expansion doesn't provide any either. – De Novo Dec 5 '18 at 5:04
  • @MichaelHomer bash isn't really where I live, so I didn't feel comfortable saying definitively that there are no cases where @ or * are sufficient. If there aren't any cases where that happens and there is a good reference, I'm happy to edit my answer to say so. – De Novo Dec 5 '18 at 5:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.