Is the behavior of escaping special characters inside double-quotes in mainstream POSIX-compliant shells at...












0














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.










share|improve this question






















  • 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
















0














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.










share|improve this question






















  • 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














0












0








0







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.










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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


















  • 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










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


}
});














draft saved

draft discarded


















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
















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





















































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

Accessing regular linux commands in Huawei's Dopra Linux

Can't connect RFCOMM socket: Host is down

Kernel panic - not syncing: Fatal Exception in Interrupt