Is the behavior of escaping special characters inside double-quotes in mainstream POSIX-compliant shells at...
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>
I interpret this to mean that should only escape one of these five special characters if it is special in its given context.
The man pages for ash, dash, bash and ksh do not contain the clause "when considered special". I take this to mean (and have confirmed through basic experimentation) that has the effect of escaping these five characters unconditionally, even when one of these five characters is not special in its given context.
Consider the output of $ echo "abcde"
, which is abcde
. This is expected because a
is not special in this context (or any context for that matter); therefore the is not special and is treated literally.
Now consider the output of $ echo "\abcde"
, which is abcde
. This is not the behavior I expect. In my mind, the first backslash in the string \abcde
should also be treated literally, because it is followed by in a context where
is not special. The output I would expect is
\abcde
.
Another scenario where I see unexpected behavior is in the output of echo "ab$"
, which is ab$
. In my mind, $
does have a special meaning it this context because it does serve to introduce paramater expansion, commmand substitution or arithmetic expansion. Therefore, in my mind, the should be treated literally because it is followed by
$
in a context where $
is not special. The output I would expect is ab$
.
For the record, I hope I am totally off base here. It makes my life that much harder having to worry about escaping these five characters only in certain circumstances. I strive to be posixly correct wherever possible, and I don't want to depend on escaping these five special characters unconditionally if this (personally desired) behavior in mainstream POSIX-compliant shells does not fall in line with POSIX.
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>
I interpret this to mean that should only escape one of these five special characters if it is special in its given context.
The man pages for ash, dash, bash and ksh do not contain the clause "when considered special". I take this to mean (and have confirmed through basic experimentation) that has the effect of escaping these five characters unconditionally, even when one of these five characters is not special in its given context.
Consider the output of $ echo "abcde"
, which is abcde
. This is expected because a
is not special in this context (or any context for that matter); therefore the is not special and is treated literally.
Now consider the output of $ echo "\abcde"
, which is abcde
. This is not the behavior I expect. In my mind, the first backslash in the string \abcde
should also be treated literally, because it is followed by in a context where
is not special. The output I would expect is
\abcde
.
Another scenario where I see unexpected behavior is in the output of echo "ab$"
, which is ab$
. In my mind, $
does have a special meaning it this context because it does serve to introduce paramater expansion, commmand substitution or arithmetic expansion. Therefore, in my mind, the should be treated literally because it is followed by
$
in a context where $
is not special. The output I would expect is ab$
.
For the record, I hope I am totally off base here. It makes my life that much harder having to worry about escaping these five characters only in certain circumstances. I strive to be posixly correct wherever possible, and I don't want to depend on escaping these five special characters unconditionally if this (personally desired) behavior in mainstream POSIX-compliant shells does not fall in line with POSIX.
shell quoting posix
Just use single quotes and you won't have to worry about any of it.
– Michael Homer
1 hour ago
@MichaelHomer If I am onto something that is what I will have to do. Just hope I am off base because otherwise, I will have to rewrite all of my scripts in a very ugly, less readable fashion to be on the safe side.
– Harold Fischer
1 hour ago
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>
I interpret this to mean that should only escape one of these five special characters if it is special in its given context.
The man pages for ash, dash, bash and ksh do not contain the clause "when considered special". I take this to mean (and have confirmed through basic experimentation) that has the effect of escaping these five characters unconditionally, even when one of these five characters is not special in its given context.
Consider the output of $ echo "abcde"
, which is abcde
. This is expected because a
is not special in this context (or any context for that matter); therefore the is not special and is treated literally.
Now consider the output of $ echo "\abcde"
, which is abcde
. This is not the behavior I expect. In my mind, the first backslash in the string \abcde
should also be treated literally, because it is followed by in a context where
is not special. The output I would expect is
\abcde
.
Another scenario where I see unexpected behavior is in the output of echo "ab$"
, which is ab$
. In my mind, $
does have a special meaning it this context because it does serve to introduce paramater expansion, commmand substitution or arithmetic expansion. Therefore, in my mind, the should be treated literally because it is followed by
$
in a context where $
is not special. The output I would expect is ab$
.
For the record, I hope I am totally off base here. It makes my life that much harder having to worry about escaping these five characters only in certain circumstances. I strive to be posixly correct wherever possible, and I don't want to depend on escaping these five special characters unconditionally if this (personally desired) behavior in mainstream POSIX-compliant shells does not fall in line with POSIX.
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>
I interpret this to mean that should only escape one of these five special characters if it is special in its given context.
The man pages for ash, dash, bash and ksh do not contain the clause "when considered special". I take this to mean (and have confirmed through basic experimentation) that has the effect of escaping these five characters unconditionally, even when one of these five characters is not special in its given context.
Consider the output of $ echo "abcde"
, which is abcde
. This is expected because a
is not special in this context (or any context for that matter); therefore the is not special and is treated literally.
Now consider the output of $ echo "\abcde"
, which is abcde
. This is not the behavior I expect. In my mind, the first backslash in the string \abcde
should also be treated literally, because it is followed by in a context where
is not special. The output I would expect is
\abcde
.
Another scenario where I see unexpected behavior is in the output of echo "ab$"
, which is ab$
. In my mind, $
does have a special meaning it this context because it does serve to introduce paramater expansion, commmand substitution or arithmetic expansion. Therefore, in my mind, the should be treated literally because it is followed by
$
in a context where $
is not special. The output I would expect is ab$
.
For the record, I hope I am totally off base here. It makes my life that much harder having to worry about escaping these five characters only in certain circumstances. I strive to be posixly correct wherever possible, and I don't want to depend on escaping these five special characters unconditionally if this (personally desired) behavior in mainstream POSIX-compliant shells does not fall in line with POSIX.
shell quoting posix
shell quoting posix
asked 1 hour ago
Harold FischerHarold Fischer
651315
651315
Just use single quotes and you won't have to worry about any of it.
– Michael Homer
1 hour ago
@MichaelHomer If I am onto something that is what I will have to do. Just hope I am off base because otherwise, I will have to rewrite all of my scripts in a very ugly, less readable fashion to be on the safe side.
– Harold Fischer
1 hour ago
add a comment |
Just use single quotes and you won't have to worry about any of it.
– Michael Homer
1 hour ago
@MichaelHomer If I am onto something that is what I will have to do. Just hope I am off base because otherwise, I will have to rewrite all of my scripts in a very ugly, less readable fashion to be on the safe side.
– Harold Fischer
1 hour ago
Just use single quotes and you won't have to worry about any of it.
– Michael Homer
1 hour ago
Just use single quotes and you won't have to worry about any of it.
– Michael Homer
1 hour ago
@MichaelHomer If I am onto something that is what I will have to do. Just hope I am off base because otherwise, I will have to rewrite all of my scripts in a very ugly, less readable fashion to be on the safe side.
– Harold Fischer
1 hour ago
@MichaelHomer If I am onto something that is what I will have to do. Just hope I am off base because otherwise, I will have to rewrite all of my scripts in a very ugly, less readable fashion to be on the safe side.
– Harold Fischer
1 hour ago
add a comment |
0
active
oldest
votes
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%2f493380%2fis-the-behavior-of-escaping-special-characters-inside-double-quotes-in-mainstrea%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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%2f493380%2fis-the-behavior-of-escaping-special-characters-inside-double-quotes-in-mainstrea%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
Just use single quotes and you won't have to worry about any of it.
– Michael Homer
1 hour ago
@MichaelHomer If I am onto something that is what I will have to do. Just hope I am off base because otherwise, I will have to rewrite all of my scripts in a very ugly, less readable fashion to be on the safe side.
– Harold Fischer
1 hour ago