Why does this `awk` command stop working within a command substitution? [on hold]











up vote
0
down vote

favorite












I have the following function:



awk '{gsub(""", "\""); print}' ORS='\n' "$1"                                                                                                                


It takes a string such as:



query GetAnimal {
getAnimal(id: "bear") {
name
}
}


and return:



query GetAnimal {n  getAnimal(id: "bear") {n    namen  }n}


It works! But when I run it as following:



variable="$(awk '{gsub(""", "\""); print}' ORS='\n' "$1")"


It doesn't work. I think it's something to do with the quotation marks, but I've tried escaping them, and I can't figure out any working syntax.



Why is this not working?










share|improve this question













put on hold as off-topic by Isaac, Archemar, G-Man, RalfFriedl, JigglyNaga Nov 15 at 11:22


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Isaac, Archemar, RalfFriedl, JigglyNaga

If this question can be reworded to fit the rules in the help center, please edit the question.









  • 3




    Possibly, it's because you're using echo "$variable" instead of printf '%sn' "$variable" to check the content of the variable. $(...) (as opposed to `...`) shouldn't make any different when it comes to backslashes, but some implementations of echo treat backslash specially. See Why is printf better than echo?
    – Stéphane Chazelas
    Nov 14 at 12:29










  • @StéphaneChazelas it's most certainly that; the echo builtin from debian's /bin/sh (dash) expands the n,t, etc. even when not given the -e flag.
    – mosvy
    Nov 14 at 14:30












  • @mosvy, dash or the sh of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requires echo -e to output -e.
    – Stéphane Chazelas
    Nov 14 at 14:34












  • @StéphaneChazelas That is very insightful information. Thank you!
    – Nick Bull
    Nov 14 at 14:39















up vote
0
down vote

favorite












I have the following function:



awk '{gsub(""", "\""); print}' ORS='\n' "$1"                                                                                                                


It takes a string such as:



query GetAnimal {
getAnimal(id: "bear") {
name
}
}


and return:



query GetAnimal {n  getAnimal(id: "bear") {n    namen  }n}


It works! But when I run it as following:



variable="$(awk '{gsub(""", "\""); print}' ORS='\n' "$1")"


It doesn't work. I think it's something to do with the quotation marks, but I've tried escaping them, and I can't figure out any working syntax.



Why is this not working?










share|improve this question













put on hold as off-topic by Isaac, Archemar, G-Man, RalfFriedl, JigglyNaga Nov 15 at 11:22


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Isaac, Archemar, RalfFriedl, JigglyNaga

If this question can be reworded to fit the rules in the help center, please edit the question.









  • 3




    Possibly, it's because you're using echo "$variable" instead of printf '%sn' "$variable" to check the content of the variable. $(...) (as opposed to `...`) shouldn't make any different when it comes to backslashes, but some implementations of echo treat backslash specially. See Why is printf better than echo?
    – Stéphane Chazelas
    Nov 14 at 12:29










  • @StéphaneChazelas it's most certainly that; the echo builtin from debian's /bin/sh (dash) expands the n,t, etc. even when not given the -e flag.
    – mosvy
    Nov 14 at 14:30












  • @mosvy, dash or the sh of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requires echo -e to output -e.
    – Stéphane Chazelas
    Nov 14 at 14:34












  • @StéphaneChazelas That is very insightful information. Thank you!
    – Nick Bull
    Nov 14 at 14:39













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I have the following function:



awk '{gsub(""", "\""); print}' ORS='\n' "$1"                                                                                                                


It takes a string such as:



query GetAnimal {
getAnimal(id: "bear") {
name
}
}


and return:



query GetAnimal {n  getAnimal(id: "bear") {n    namen  }n}


It works! But when I run it as following:



variable="$(awk '{gsub(""", "\""); print}' ORS='\n' "$1")"


It doesn't work. I think it's something to do with the quotation marks, but I've tried escaping them, and I can't figure out any working syntax.



Why is this not working?










share|improve this question













I have the following function:



awk '{gsub(""", "\""); print}' ORS='\n' "$1"                                                                                                                


It takes a string such as:



query GetAnimal {
getAnimal(id: "bear") {
name
}
}


and return:



query GetAnimal {n  getAnimal(id: "bear") {n    namen  }n}


It works! But when I run it as following:



variable="$(awk '{gsub(""", "\""); print}' ORS='\n' "$1")"


It doesn't work. I think it's something to do with the quotation marks, but I've tried escaping them, and I can't figure out any working syntax.



Why is this not working?







shell awk command-substitution






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 14 at 12:09









Nick Bull

1528




1528




put on hold as off-topic by Isaac, Archemar, G-Man, RalfFriedl, JigglyNaga Nov 15 at 11:22


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Isaac, Archemar, RalfFriedl, JigglyNaga

If this question can be reworded to fit the rules in the help center, please edit the question.




put on hold as off-topic by Isaac, Archemar, G-Man, RalfFriedl, JigglyNaga Nov 15 at 11:22


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Isaac, Archemar, RalfFriedl, JigglyNaga

If this question can be reworded to fit the rules in the help center, please edit the question.








  • 3




    Possibly, it's because you're using echo "$variable" instead of printf '%sn' "$variable" to check the content of the variable. $(...) (as opposed to `...`) shouldn't make any different when it comes to backslashes, but some implementations of echo treat backslash specially. See Why is printf better than echo?
    – Stéphane Chazelas
    Nov 14 at 12:29










  • @StéphaneChazelas it's most certainly that; the echo builtin from debian's /bin/sh (dash) expands the n,t, etc. even when not given the -e flag.
    – mosvy
    Nov 14 at 14:30












  • @mosvy, dash or the sh of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requires echo -e to output -e.
    – Stéphane Chazelas
    Nov 14 at 14:34












  • @StéphaneChazelas That is very insightful information. Thank you!
    – Nick Bull
    Nov 14 at 14:39














  • 3




    Possibly, it's because you're using echo "$variable" instead of printf '%sn' "$variable" to check the content of the variable. $(...) (as opposed to `...`) shouldn't make any different when it comes to backslashes, but some implementations of echo treat backslash specially. See Why is printf better than echo?
    – Stéphane Chazelas
    Nov 14 at 12:29










  • @StéphaneChazelas it's most certainly that; the echo builtin from debian's /bin/sh (dash) expands the n,t, etc. even when not given the -e flag.
    – mosvy
    Nov 14 at 14:30












  • @mosvy, dash or the sh of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requires echo -e to output -e.
    – Stéphane Chazelas
    Nov 14 at 14:34












  • @StéphaneChazelas That is very insightful information. Thank you!
    – Nick Bull
    Nov 14 at 14:39








3




3




Possibly, it's because you're using echo "$variable" instead of printf '%sn' "$variable" to check the content of the variable. $(...) (as opposed to `...`) shouldn't make any different when it comes to backslashes, but some implementations of echo treat backslash specially. See Why is printf better than echo?
– Stéphane Chazelas
Nov 14 at 12:29




Possibly, it's because you're using echo "$variable" instead of printf '%sn' "$variable" to check the content of the variable. $(...) (as opposed to `...`) shouldn't make any different when it comes to backslashes, but some implementations of echo treat backslash specially. See Why is printf better than echo?
– Stéphane Chazelas
Nov 14 at 12:29












@StéphaneChazelas it's most certainly that; the echo builtin from debian's /bin/sh (dash) expands the n,t, etc. even when not given the -e flag.
– mosvy
Nov 14 at 14:30






@StéphaneChazelas it's most certainly that; the echo builtin from debian's /bin/sh (dash) expands the n,t, etc. even when not given the -e flag.
– mosvy
Nov 14 at 14:30














@mosvy, dash or the sh of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requires echo -e to output -e.
– Stéphane Chazelas
Nov 14 at 14:34






@mosvy, dash or the sh of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requires echo -e to output -e.
– Stéphane Chazelas
Nov 14 at 14:34














@StéphaneChazelas That is very insightful information. Thank you!
– Nick Bull
Nov 14 at 14:39




@StéphaneChazelas That is very insightful information. Thank you!
– Nick Bull
Nov 14 at 14:39










1 Answer
1






active

oldest

votes

















up vote
0
down vote













While the `...` ancient form of command substitution does some extra backslash processing, the $(...) one doesn't (one of the reasons why it should be preferred over `...`.



As long as the output of cmd doesn't end in newline characters (as is the case in your example) and (except in zsh) doesn't contain NUL character and (in yash) doesn't contain byte sequences not forming valid characters



cmd


Should produce the same output¹ (standard output) as:



output=$(cmd); printf %s "$output"


$output will contain the exact output of cmd stripped of all trailing newline characters.



Here, most likely, I think you ran echo "$variable" to check the content of the variable and saw that \ were turned in and n into newline characters.



But that's not $(...)'s fault, it would be echo's. echo does expand the escape sequences in its arguments (though some implementations only do it when passed a non-standard -e option).



Generally, you can't use echo to output arbitrary data, use printf instead.





¹ Strictly speaking, when using command substitution, cmd's stdout become a pipe. cmd could decide to produce a different output when its stdout is not a terminal or is not seekable...






share|improve this answer




























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    While the `...` ancient form of command substitution does some extra backslash processing, the $(...) one doesn't (one of the reasons why it should be preferred over `...`.



    As long as the output of cmd doesn't end in newline characters (as is the case in your example) and (except in zsh) doesn't contain NUL character and (in yash) doesn't contain byte sequences not forming valid characters



    cmd


    Should produce the same output¹ (standard output) as:



    output=$(cmd); printf %s "$output"


    $output will contain the exact output of cmd stripped of all trailing newline characters.



    Here, most likely, I think you ran echo "$variable" to check the content of the variable and saw that \ were turned in and n into newline characters.



    But that's not $(...)'s fault, it would be echo's. echo does expand the escape sequences in its arguments (though some implementations only do it when passed a non-standard -e option).



    Generally, you can't use echo to output arbitrary data, use printf instead.





    ¹ Strictly speaking, when using command substitution, cmd's stdout become a pipe. cmd could decide to produce a different output when its stdout is not a terminal or is not seekable...






    share|improve this answer

























      up vote
      0
      down vote













      While the `...` ancient form of command substitution does some extra backslash processing, the $(...) one doesn't (one of the reasons why it should be preferred over `...`.



      As long as the output of cmd doesn't end in newline characters (as is the case in your example) and (except in zsh) doesn't contain NUL character and (in yash) doesn't contain byte sequences not forming valid characters



      cmd


      Should produce the same output¹ (standard output) as:



      output=$(cmd); printf %s "$output"


      $output will contain the exact output of cmd stripped of all trailing newline characters.



      Here, most likely, I think you ran echo "$variable" to check the content of the variable and saw that \ were turned in and n into newline characters.



      But that's not $(...)'s fault, it would be echo's. echo does expand the escape sequences in its arguments (though some implementations only do it when passed a non-standard -e option).



      Generally, you can't use echo to output arbitrary data, use printf instead.





      ¹ Strictly speaking, when using command substitution, cmd's stdout become a pipe. cmd could decide to produce a different output when its stdout is not a terminal or is not seekable...






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        While the `...` ancient form of command substitution does some extra backslash processing, the $(...) one doesn't (one of the reasons why it should be preferred over `...`.



        As long as the output of cmd doesn't end in newline characters (as is the case in your example) and (except in zsh) doesn't contain NUL character and (in yash) doesn't contain byte sequences not forming valid characters



        cmd


        Should produce the same output¹ (standard output) as:



        output=$(cmd); printf %s "$output"


        $output will contain the exact output of cmd stripped of all trailing newline characters.



        Here, most likely, I think you ran echo "$variable" to check the content of the variable and saw that \ were turned in and n into newline characters.



        But that's not $(...)'s fault, it would be echo's. echo does expand the escape sequences in its arguments (though some implementations only do it when passed a non-standard -e option).



        Generally, you can't use echo to output arbitrary data, use printf instead.





        ¹ Strictly speaking, when using command substitution, cmd's stdout become a pipe. cmd could decide to produce a different output when its stdout is not a terminal or is not seekable...






        share|improve this answer












        While the `...` ancient form of command substitution does some extra backslash processing, the $(...) one doesn't (one of the reasons why it should be preferred over `...`.



        As long as the output of cmd doesn't end in newline characters (as is the case in your example) and (except in zsh) doesn't contain NUL character and (in yash) doesn't contain byte sequences not forming valid characters



        cmd


        Should produce the same output¹ (standard output) as:



        output=$(cmd); printf %s "$output"


        $output will contain the exact output of cmd stripped of all trailing newline characters.



        Here, most likely, I think you ran echo "$variable" to check the content of the variable and saw that \ were turned in and n into newline characters.



        But that's not $(...)'s fault, it would be echo's. echo does expand the escape sequences in its arguments (though some implementations only do it when passed a non-standard -e option).



        Generally, you can't use echo to output arbitrary data, use printf instead.





        ¹ Strictly speaking, when using command substitution, cmd's stdout become a pipe. cmd could decide to produce a different output when its stdout is not a terminal or is not seekable...







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 14 at 15:22









        Stéphane Chazelas

        293k54551891




        293k54551891















            Popular posts from this blog

            Morgemoulin

            Scott Moir

            Souastre