Why does this `awk` command stop working within a command substitution? [on hold]
Clash Royale CLAN TAG#URR8PPP
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?
shell awk command-substitution
put on hold as off-topic by Isaac, Archemar, G-Man, RalfFriedl, JigglyNaga 13 hours ago
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
add a comment |
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?
shell awk command-substitution
put on hold as off-topic by Isaac, Archemar, G-Man, RalfFriedl, JigglyNaga 13 hours ago
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
3
Possibly, it's because you're usingecho "$variable"
instead ofprintf '%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 ofecho
treat backslash specially. See Why is printf better than echo?
– Stéphane Chazelas
yesterday
@StéphaneChazelas it's most certainly that; theecho
builtin from debian's/bin/sh
(dash
) expands then
,t
, etc. even when not given the-e
flag.
– mosvy
yesterday
@mosvy,dash
or thesh
of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requiresecho -e
to output-e
.
– Stéphane Chazelas
yesterday
@StéphaneChazelas That is very insightful information. Thank you!
– Nick Bull
yesterday
add a comment |
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?
shell awk command-substitution
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
shell awk command-substitution
asked yesterday
Nick Bull
1528
1528
put on hold as off-topic by Isaac, Archemar, G-Man, RalfFriedl, JigglyNaga 13 hours ago
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
put on hold as off-topic by Isaac, Archemar, G-Man, RalfFriedl, JigglyNaga 13 hours ago
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
3
Possibly, it's because you're usingecho "$variable"
instead ofprintf '%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 ofecho
treat backslash specially. See Why is printf better than echo?
– Stéphane Chazelas
yesterday
@StéphaneChazelas it's most certainly that; theecho
builtin from debian's/bin/sh
(dash
) expands then
,t
, etc. even when not given the-e
flag.
– mosvy
yesterday
@mosvy,dash
or thesh
of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requiresecho -e
to output-e
.
– Stéphane Chazelas
yesterday
@StéphaneChazelas That is very insightful information. Thank you!
– Nick Bull
yesterday
add a comment |
3
Possibly, it's because you're usingecho "$variable"
instead ofprintf '%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 ofecho
treat backslash specially. See Why is printf better than echo?
– Stéphane Chazelas
yesterday
@StéphaneChazelas it's most certainly that; theecho
builtin from debian's/bin/sh
(dash
) expands then
,t
, etc. even when not given the-e
flag.
– mosvy
yesterday
@mosvy,dash
or thesh
of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requiresecho -e
to output-e
.
– Stéphane Chazelas
yesterday
@StéphaneChazelas That is very insightful information. Thank you!
– Nick Bull
yesterday
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
yesterday
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
yesterday
@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
yesterday
@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
yesterday
@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
yesterday
@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
yesterday
@StéphaneChazelas That is very insightful information. Thank you!
– Nick Bull
yesterday
@StéphaneChazelas That is very insightful information. Thank you!
– Nick Bull
yesterday
add a comment |
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...
add a comment |
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...
add a comment |
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...
add a comment |
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...
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...
answered yesterday
Stéphane Chazelas
293k54547888
293k54547888
add a comment |
add a comment |
3
Possibly, it's because you're using
echo "$variable"
instead ofprintf '%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 ofecho
treat backslash specially. See Why is printf better than echo?– Stéphane Chazelas
yesterday
@StéphaneChazelas it's most certainly that; the
echo
builtin from debian's/bin/sh
(dash
) expands then
,t
, etc. even when not given the-e
flag.– mosvy
yesterday
@mosvy,
dash
or thesh
of any UNIX system, that's a POSIX+XSI requirement. POSIX currently requiresecho -e
to output-e
.– Stéphane Chazelas
yesterday
@StéphaneChazelas That is very insightful information. Thank you!
– Nick Bull
yesterday