Does process substitution need to be double quoted?

The name of the pictureThe name of the pictureThe name of the pictureClash 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.










share|improve this question























  • 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















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.










share|improve this question























  • 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













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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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

















  • 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
















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











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.






share|improve this answer



























    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.






    share|improve this answer






















    • 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










    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
    );



    );













    draft saved

    draft discarded


















    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.






    share|improve this answer
























      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.






      share|improve this answer






















        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 4 at 23:54









        Michael Homer

        45k7119159




        45k7119159






















            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.






            share|improve this answer






















            • 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














            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.






            share|improve this answer






















            • 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












            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.






            share|improve this answer














            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.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            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
















            • 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

















            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay