POSIX Shell: inside of double-quotes, are there cases where `` fails to escape `$`, ```, `"`, `` or ``?
Clash Royale CLAN TAG#URR8PPP
Per the POSIX Shell Command Language Page:
The<backslash>
shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special:$
`
"
<newline>
This would seem to imply that escaping these five characters with a backslash would not have the effect of escaping them and having them be treated literally if they are not "special".
Am I interpreting this correctly, and if so, are there cases where escaping one of these five special characters with a would not have the intended effect of escaping it?
shell quoting posix
add a comment |
Per the POSIX Shell Command Language Page:
The<backslash>
shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special:$
`
"
<newline>
This would seem to imply that escaping these five characters with a backslash would not have the effect of escaping them and having them be treated literally if they are not "special".
Am I interpreting this correctly, and if so, are there cases where escaping one of these five special characters with a would not have the intended effect of escaping it?
shell quoting posix
It seems to imply to me that there might be times where both the backslash and the$
were to be included literally, not that the$
might retain a special meaning despite a preceding backslash. Is that what you read it as, or not?
– Michael Homer
Jan 6 at 21:13
1
The meaning is that for example in" dog n cat"
then
is 2 characters, asn
is not a dollar, backquote, .... The point is that backslash normally quotes everything, but inside double quotes it only quotes the 5 listed characters.
– icarus
Jan 6 at 21:27
The solution in that case would probably be to un-mangle the question and ask another question that said what you wanted.
– Michael Homer
Jan 7 at 3:23
add a comment |
Per the POSIX Shell Command Language Page:
The<backslash>
shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special:$
`
"
<newline>
This would seem to imply that escaping these five characters with a backslash would not have the effect of escaping them and having them be treated literally if they are not "special".
Am I interpreting this correctly, and if so, are there cases where escaping one of these five special characters with a would not have the intended effect of escaping it?
shell quoting posix
Per the POSIX Shell Command Language Page:
The<backslash>
shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special:$
`
"
<newline>
This would seem to imply that escaping these five characters with a backslash would not have the effect of escaping them and having them be treated literally if they are not "special".
Am I interpreting this correctly, and if so, are there cases where escaping one of these five special characters with a would not have the intended effect of escaping it?
shell quoting posix
shell quoting posix
edited Jan 8 at 21:33
Harold Fischer
asked Jan 6 at 20:51
Harold FischerHarold Fischer
663315
663315
It seems to imply to me that there might be times where both the backslash and the$
were to be included literally, not that the$
might retain a special meaning despite a preceding backslash. Is that what you read it as, or not?
– Michael Homer
Jan 6 at 21:13
1
The meaning is that for example in" dog n cat"
then
is 2 characters, asn
is not a dollar, backquote, .... The point is that backslash normally quotes everything, but inside double quotes it only quotes the 5 listed characters.
– icarus
Jan 6 at 21:27
The solution in that case would probably be to un-mangle the question and ask another question that said what you wanted.
– Michael Homer
Jan 7 at 3:23
add a comment |
It seems to imply to me that there might be times where both the backslash and the$
were to be included literally, not that the$
might retain a special meaning despite a preceding backslash. Is that what you read it as, or not?
– Michael Homer
Jan 6 at 21:13
1
The meaning is that for example in" dog n cat"
then
is 2 characters, asn
is not a dollar, backquote, .... The point is that backslash normally quotes everything, but inside double quotes it only quotes the 5 listed characters.
– icarus
Jan 6 at 21:27
The solution in that case would probably be to un-mangle the question and ask another question that said what you wanted.
– Michael Homer
Jan 7 at 3:23
It seems to imply to me that there might be times where both the backslash and the
$
were to be included literally, not that the $
might retain a special meaning despite a preceding backslash. Is that what you read it as, or not?– Michael Homer
Jan 6 at 21:13
It seems to imply to me that there might be times where both the backslash and the
$
were to be included literally, not that the $
might retain a special meaning despite a preceding backslash. Is that what you read it as, or not?– Michael Homer
Jan 6 at 21:13
1
1
The meaning is that for example in
" dog n cat"
the n
is 2 characters, as n
is not a dollar, backquote, .... The point is that backslash normally quotes everything, but inside double quotes it only quotes the 5 listed characters.– icarus
Jan 6 at 21:27
The meaning is that for example in
" dog n cat"
the n
is 2 characters, as n
is not a dollar, backquote, .... The point is that backslash normally quotes everything, but inside double quotes it only quotes the 5 listed characters.– icarus
Jan 6 at 21:27
The solution in that case would probably be to un-mangle the question and ask another question that said what you wanted.
– Michael Homer
Jan 7 at 3:23
The solution in that case would probably be to un-mangle the question and ask another question that said what you wanted.
– Michael Homer
Jan 7 at 3:23
add a comment |
2 Answers
2
active
oldest
votes
@MichaelHomer explains it very well. Let's try a few practical cases with PS1='$ '
:
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$ echo "after$"
after$
So $
is only "special" before a word, making it a parameter substitution. What happens if we put a backslash before all of them?
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$before
$ echo "after$"
after$
Only the "special" line changes - the dollar sign is now considered literal. It was always considered literal. What happens with other characters?
$ echo " at start"
at start
$ echo "at end "
> ^C
$ echo "before"
before
$ echo "after"
> ^C
So backslash is just another literal character before a non-special character. (^C is where I had to cancel the command line because the quote character had been escaped.)
add a comment |
Lets try to simplify.
The text, as written is:
The <backslash> shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special:
We can convert some parts of it:
The <backslash> ==> The B
... shall retain its special meaning as an escape character
... __________/------------------------__________________/
==> still is -------------------------------- an escape character
==> still is an escapeAs it was in un-quoted strings.
... only
... when followed by one of the following characters
==> A B before [$`"NL]... when considered special
Then, 1,2,and 4 read as: B still is an escape before [$`"NL]
The controversial part is: when considered special
What is being considered special ?
I believe that it is >> "the characters" << . As written:
one of the following characters when considered special:
Q: For example: when is a
"
special (inside double quotes)?A: Always (not considering nested structures like
echo "$(sed 's/["]//' file)"
).So, a backslash will always quote a
"
:echo "a"b"b""
(again: no nested structures).Then, 1,2,3,4 and 5 should read as:
B still is an escape only before special [$`"NL]
Then, the answer to your question:
are there cases where
fails to escape
$
, ```,"
,or
<newline>
?
Is: YES, when the characters [$`"NL] are not special.
They (the characters) may be not special inside nested structures (for example) yet inside quotes.
1
That's also the only explanation I can think of. But still, that specification would still be broken in that NL is not special inside double quote (when not part of expansions), butNL
still has its special line-continuation meaning. I think we should bring it to the austin-group for clarification.
– Stéphane Chazelas
Jan 9 at 9:42
Another possible explanation is the interaction with the`...`
form or command substitution. For instance$HOME
is expanded inecho `echo "$HOME"`
. So maybe it's about backslash not being special there (I doubt it though).
– Stéphane Chazelas
Jan 9 at 9:47
In 2.2.1 the spec states that: The <backslash> and <newline> shall be removed before splitting the input into tokens.. Also repeated at 2.10.2 Also note that line joining is done before tokenization, as described in Escape Character (Backslash),. So, it follows that the shell doesn't see the line-continuation for tokenization. Maybe that's the reason for the slip. But yes, it looks like an slip about the NL.
– Isaac
Jan 9 at 10:08
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',
autoActivateHeartbeat: false,
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%2f492880%2fposix-shell-inside-of-double-quotes-are-there-cases-where-fails-to-escape%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
@MichaelHomer explains it very well. Let's try a few practical cases with PS1='$ '
:
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$ echo "after$"
after$
So $
is only "special" before a word, making it a parameter substitution. What happens if we put a backslash before all of them?
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$before
$ echo "after$"
after$
Only the "special" line changes - the dollar sign is now considered literal. It was always considered literal. What happens with other characters?
$ echo " at start"
at start
$ echo "at end "
> ^C
$ echo "before"
before
$ echo "after"
> ^C
So backslash is just another literal character before a non-special character. (^C is where I had to cancel the command line because the quote character had been escaped.)
add a comment |
@MichaelHomer explains it very well. Let's try a few practical cases with PS1='$ '
:
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$ echo "after$"
after$
So $
is only "special" before a word, making it a parameter substitution. What happens if we put a backslash before all of them?
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$before
$ echo "after$"
after$
Only the "special" line changes - the dollar sign is now considered literal. It was always considered literal. What happens with other characters?
$ echo " at start"
at start
$ echo "at end "
> ^C
$ echo "before"
before
$ echo "after"
> ^C
So backslash is just another literal character before a non-special character. (^C is where I had to cancel the command line because the quote character had been escaped.)
add a comment |
@MichaelHomer explains it very well. Let's try a few practical cases with PS1='$ '
:
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$ echo "after$"
after$
So $
is only "special" before a word, making it a parameter substitution. What happens if we put a backslash before all of them?
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$before
$ echo "after$"
after$
Only the "special" line changes - the dollar sign is now considered literal. It was always considered literal. What happens with other characters?
$ echo " at start"
at start
$ echo "at end "
> ^C
$ echo "before"
before
$ echo "after"
> ^C
So backslash is just another literal character before a non-special character. (^C is where I had to cancel the command line because the quote character had been escaped.)
@MichaelHomer explains it very well. Let's try a few practical cases with PS1='$ '
:
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$ echo "after$"
after$
So $
is only "special" before a word, making it a parameter substitution. What happens if we put a backslash before all of them?
$ echo "$ at start"
$ at start
$ echo "at end $"
at end $
$ echo "$before"
$before
$ echo "after$"
after$
Only the "special" line changes - the dollar sign is now considered literal. It was always considered literal. What happens with other characters?
$ echo " at start"
at start
$ echo "at end "
> ^C
$ echo "before"
before
$ echo "after"
> ^C
So backslash is just another literal character before a non-special character. (^C is where I had to cancel the command line because the quote character had been escaped.)
answered Jan 6 at 22:14
l0b0l0b0
27.9k17118246
27.9k17118246
add a comment |
add a comment |
Lets try to simplify.
The text, as written is:
The <backslash> shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special:
We can convert some parts of it:
The <backslash> ==> The B
... shall retain its special meaning as an escape character
... __________/------------------------__________________/
==> still is -------------------------------- an escape character
==> still is an escapeAs it was in un-quoted strings.
... only
... when followed by one of the following characters
==> A B before [$`"NL]... when considered special
Then, 1,2,and 4 read as: B still is an escape before [$`"NL]
The controversial part is: when considered special
What is being considered special ?
I believe that it is >> "the characters" << . As written:
one of the following characters when considered special:
Q: For example: when is a
"
special (inside double quotes)?A: Always (not considering nested structures like
echo "$(sed 's/["]//' file)"
).So, a backslash will always quote a
"
:echo "a"b"b""
(again: no nested structures).Then, 1,2,3,4 and 5 should read as:
B still is an escape only before special [$`"NL]
Then, the answer to your question:
are there cases where
fails to escape
$
, ```,"
,or
<newline>
?
Is: YES, when the characters [$`"NL] are not special.
They (the characters) may be not special inside nested structures (for example) yet inside quotes.
1
That's also the only explanation I can think of. But still, that specification would still be broken in that NL is not special inside double quote (when not part of expansions), butNL
still has its special line-continuation meaning. I think we should bring it to the austin-group for clarification.
– Stéphane Chazelas
Jan 9 at 9:42
Another possible explanation is the interaction with the`...`
form or command substitution. For instance$HOME
is expanded inecho `echo "$HOME"`
. So maybe it's about backslash not being special there (I doubt it though).
– Stéphane Chazelas
Jan 9 at 9:47
In 2.2.1 the spec states that: The <backslash> and <newline> shall be removed before splitting the input into tokens.. Also repeated at 2.10.2 Also note that line joining is done before tokenization, as described in Escape Character (Backslash),. So, it follows that the shell doesn't see the line-continuation for tokenization. Maybe that's the reason for the slip. But yes, it looks like an slip about the NL.
– Isaac
Jan 9 at 10:08
add a comment |
Lets try to simplify.
The text, as written is:
The <backslash> shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special:
We can convert some parts of it:
The <backslash> ==> The B
... shall retain its special meaning as an escape character
... __________/------------------------__________________/
==> still is -------------------------------- an escape character
==> still is an escapeAs it was in un-quoted strings.
... only
... when followed by one of the following characters
==> A B before [$`"NL]... when considered special
Then, 1,2,and 4 read as: B still is an escape before [$`"NL]
The controversial part is: when considered special
What is being considered special ?
I believe that it is >> "the characters" << . As written:
one of the following characters when considered special:
Q: For example: when is a
"
special (inside double quotes)?A: Always (not considering nested structures like
echo "$(sed 's/["]//' file)"
).So, a backslash will always quote a
"
:echo "a"b"b""
(again: no nested structures).Then, 1,2,3,4 and 5 should read as:
B still is an escape only before special [$`"NL]
Then, the answer to your question:
are there cases where
fails to escape
$
, ```,"
,or
<newline>
?
Is: YES, when the characters [$`"NL] are not special.
They (the characters) may be not special inside nested structures (for example) yet inside quotes.
1
That's also the only explanation I can think of. But still, that specification would still be broken in that NL is not special inside double quote (when not part of expansions), butNL
still has its special line-continuation meaning. I think we should bring it to the austin-group for clarification.
– Stéphane Chazelas
Jan 9 at 9:42
Another possible explanation is the interaction with the`...`
form or command substitution. For instance$HOME
is expanded inecho `echo "$HOME"`
. So maybe it's about backslash not being special there (I doubt it though).
– Stéphane Chazelas
Jan 9 at 9:47
In 2.2.1 the spec states that: The <backslash> and <newline> shall be removed before splitting the input into tokens.. Also repeated at 2.10.2 Also note that line joining is done before tokenization, as described in Escape Character (Backslash),. So, it follows that the shell doesn't see the line-continuation for tokenization. Maybe that's the reason for the slip. But yes, it looks like an slip about the NL.
– Isaac
Jan 9 at 10:08
add a comment |
Lets try to simplify.
The text, as written is:
The <backslash> shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special:
We can convert some parts of it:
The <backslash> ==> The B
... shall retain its special meaning as an escape character
... __________/------------------------__________________/
==> still is -------------------------------- an escape character
==> still is an escapeAs it was in un-quoted strings.
... only
... when followed by one of the following characters
==> A B before [$`"NL]... when considered special
Then, 1,2,and 4 read as: B still is an escape before [$`"NL]
The controversial part is: when considered special
What is being considered special ?
I believe that it is >> "the characters" << . As written:
one of the following characters when considered special:
Q: For example: when is a
"
special (inside double quotes)?A: Always (not considering nested structures like
echo "$(sed 's/["]//' file)"
).So, a backslash will always quote a
"
:echo "a"b"b""
(again: no nested structures).Then, 1,2,3,4 and 5 should read as:
B still is an escape only before special [$`"NL]
Then, the answer to your question:
are there cases where
fails to escape
$
, ```,"
,or
<newline>
?
Is: YES, when the characters [$`"NL] are not special.
They (the characters) may be not special inside nested structures (for example) yet inside quotes.
Lets try to simplify.
The text, as written is:
The <backslash> shall retain its special meaning as an escape character (see Escape Character (Backslash)) only when followed by one of the following characters when considered special:
We can convert some parts of it:
The <backslash> ==> The B
... shall retain its special meaning as an escape character
... __________/------------------------__________________/
==> still is -------------------------------- an escape character
==> still is an escapeAs it was in un-quoted strings.
... only
... when followed by one of the following characters
==> A B before [$`"NL]... when considered special
Then, 1,2,and 4 read as: B still is an escape before [$`"NL]
The controversial part is: when considered special
What is being considered special ?
I believe that it is >> "the characters" << . As written:
one of the following characters when considered special:
Q: For example: when is a
"
special (inside double quotes)?A: Always (not considering nested structures like
echo "$(sed 's/["]//' file)"
).So, a backslash will always quote a
"
:echo "a"b"b""
(again: no nested structures).Then, 1,2,3,4 and 5 should read as:
B still is an escape only before special [$`"NL]
Then, the answer to your question:
are there cases where
fails to escape
$
, ```,"
,or
<newline>
?
Is: YES, when the characters [$`"NL] are not special.
They (the characters) may be not special inside nested structures (for example) yet inside quotes.
answered Jan 9 at 9:32
IsaacIsaac
11.6k11652
11.6k11652
1
That's also the only explanation I can think of. But still, that specification would still be broken in that NL is not special inside double quote (when not part of expansions), butNL
still has its special line-continuation meaning. I think we should bring it to the austin-group for clarification.
– Stéphane Chazelas
Jan 9 at 9:42
Another possible explanation is the interaction with the`...`
form or command substitution. For instance$HOME
is expanded inecho `echo "$HOME"`
. So maybe it's about backslash not being special there (I doubt it though).
– Stéphane Chazelas
Jan 9 at 9:47
In 2.2.1 the spec states that: The <backslash> and <newline> shall be removed before splitting the input into tokens.. Also repeated at 2.10.2 Also note that line joining is done before tokenization, as described in Escape Character (Backslash),. So, it follows that the shell doesn't see the line-continuation for tokenization. Maybe that's the reason for the slip. But yes, it looks like an slip about the NL.
– Isaac
Jan 9 at 10:08
add a comment |
1
That's also the only explanation I can think of. But still, that specification would still be broken in that NL is not special inside double quote (when not part of expansions), butNL
still has its special line-continuation meaning. I think we should bring it to the austin-group for clarification.
– Stéphane Chazelas
Jan 9 at 9:42
Another possible explanation is the interaction with the`...`
form or command substitution. For instance$HOME
is expanded inecho `echo "$HOME"`
. So maybe it's about backslash not being special there (I doubt it though).
– Stéphane Chazelas
Jan 9 at 9:47
In 2.2.1 the spec states that: The <backslash> and <newline> shall be removed before splitting the input into tokens.. Also repeated at 2.10.2 Also note that line joining is done before tokenization, as described in Escape Character (Backslash),. So, it follows that the shell doesn't see the line-continuation for tokenization. Maybe that's the reason for the slip. But yes, it looks like an slip about the NL.
– Isaac
Jan 9 at 10:08
1
1
That's also the only explanation I can think of. But still, that specification would still be broken in that NL is not special inside double quote (when not part of expansions), but
NL
still has its special line-continuation meaning. I think we should bring it to the austin-group for clarification.– Stéphane Chazelas
Jan 9 at 9:42
That's also the only explanation I can think of. But still, that specification would still be broken in that NL is not special inside double quote (when not part of expansions), but
NL
still has its special line-continuation meaning. I think we should bring it to the austin-group for clarification.– Stéphane Chazelas
Jan 9 at 9:42
Another possible explanation is the interaction with the
`...`
form or command substitution. For instance $HOME
is expanded in echo `echo "$HOME"`
. So maybe it's about backslash not being special there (I doubt it though).– Stéphane Chazelas
Jan 9 at 9:47
Another possible explanation is the interaction with the
`...`
form or command substitution. For instance $HOME
is expanded in echo `echo "$HOME"`
. So maybe it's about backslash not being special there (I doubt it though).– Stéphane Chazelas
Jan 9 at 9:47
In 2.2.1 the spec states that: The <backslash> and <newline> shall be removed before splitting the input into tokens.. Also repeated at 2.10.2 Also note that line joining is done before tokenization, as described in Escape Character (Backslash),. So, it follows that the shell doesn't see the line-continuation for tokenization. Maybe that's the reason for the slip. But yes, it looks like an slip about the NL.
– Isaac
Jan 9 at 10:08
In 2.2.1 the spec states that: The <backslash> and <newline> shall be removed before splitting the input into tokens.. Also repeated at 2.10.2 Also note that line joining is done before tokenization, as described in Escape Character (Backslash),. So, it follows that the shell doesn't see the line-continuation for tokenization. Maybe that's the reason for the slip. But yes, it looks like an slip about the NL.
– Isaac
Jan 9 at 10:08
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.
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%2f492880%2fposix-shell-inside-of-double-quotes-are-there-cases-where-fails-to-escape%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
It seems to imply to me that there might be times where both the backslash and the
$
were to be included literally, not that the$
might retain a special meaning despite a preceding backslash. Is that what you read it as, or not?– Michael Homer
Jan 6 at 21:13
1
The meaning is that for example in
" dog n cat"
then
is 2 characters, asn
is not a dollar, backquote, .... The point is that backslash normally quotes everything, but inside double quotes it only quotes the 5 listed characters.– icarus
Jan 6 at 21:27
The solution in that case would probably be to un-mangle the question and ask another question that said what you wanted.
– Michael Homer
Jan 7 at 3:23