Does process substitution need to be double quoted?
Clash Royale CLAN TAG#URR8PPP
up vote
-5
down vote
favorite
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.
bash quoting process-substitution
add a comment |
up vote
-5
down vote
favorite
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.
bash quoting process-substitution
Are you asking about$(…)
,<(…)
,>(…)
?
– ctrl-alt-delor
Dec 4 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 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 settingIFS
the/
:bash -c 'IFS=/; x=/dev/fd/1; printf "%sn" <(sleep 10) $x'
; only the$x
will be split.
– mosvy
Dec 4 at 23:02
add a comment |
up vote
-5
down vote
favorite
up vote
-5
down vote
favorite
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.
bash quoting process-substitution
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.
bash quoting process-substitution
bash quoting process-substitution
edited Dec 4 at 23:17
Jeff Schaller
37.8k1053122
37.8k1053122
asked Dec 4 at 22:34
Tim
25.4k74243447
25.4k74243447
Are you asking about$(…)
,<(…)
,>(…)
?
– ctrl-alt-delor
Dec 4 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 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 settingIFS
the/
:bash -c 'IFS=/; x=/dev/fd/1; printf "%sn" <(sleep 10) $x'
; only the$x
will be split.
– mosvy
Dec 4 at 23:02
add a comment |
Are you asking about$(…)
,<(…)
,>(…)
?
– ctrl-alt-delor
Dec 4 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 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 settingIFS
the/
:bash -c 'IFS=/; x=/dev/fd/1; printf "%sn" <(sleep 10) $x'
; only the$x
will be split.
– mosvy
Dec 4 at 23:02
Are you asking about
$(…)
, <(…)
, >(…)
?– ctrl-alt-delor
Dec 4 at 22:39
Are you asking about
$(…)
, <(…)
, >(…)
?– ctrl-alt-delor
Dec 4 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 at 22:48
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 at 22:48
3
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 "%sn" <(sleep 10) $x'
; only the $x
will be split.– mosvy
Dec 4 at 23:02
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 "%sn" <(sleep 10) $x'
; only the $x
will be split.– mosvy
Dec 4 at 23:02
add a comment |
2 Answers
2
active
oldest
votes
up vote
5
down vote
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.
add a comment |
up vote
1
down vote
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 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 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 at 5:17
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f486019%2fdoes-process-substitution-need-to-be-double-quoted%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
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.
add a comment |
up vote
5
down vote
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.
add a comment |
up vote
5
down vote
up vote
5
down vote
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.
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.
answered Dec 4 at 23:54
Michael Homer
45k7119159
45k7119159
add a comment |
add a comment |
up vote
1
down vote
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 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 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 at 5:17
add a comment |
up vote
1
down vote
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 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 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 at 5:17
add a comment |
up vote
1
down vote
up vote
1
down vote
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.
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.
edited Dec 5 at 5:27
answered Dec 5 at 4:01
De Novo
1156
1156
When do@
and*
cause something to happen inside double quotes?
– Michael Homer
Dec 5 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 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 at 5:17
add a comment |
When do@
and*
cause something to happen inside double quotes?
– Michael Homer
Dec 5 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 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 at 5:17
When do
@
and *
cause something to happen inside double quotes?– Michael Homer
Dec 5 at 4:54
When do
@
and *
cause something to happen inside double quotes?– Michael Homer
Dec 5 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 at 5:04
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 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 at 5:17
@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 at 5:17
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f486019%2fdoes-process-substitution-need-to-be-double-quoted%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Are you asking about
$(…)
,<(…)
,>(…)
?– ctrl-alt-delor
Dec 4 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 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 "%sn" <(sleep 10) $x'
; only the$x
will be split.– mosvy
Dec 4 at 23:02