Date: Mon, 14 Sep 2020 12:04:02 -0400 From: Chet Ramey <chet.ra...@case.edu> Message-ID: <6377c2e5-b496-8a80-2f86-d70a6f825...@case.edu>
| "However, the double-quote character ( '"' ) [edited, since the HTML on the | web site is malformed] So it is, what a mess, the pdf formatted version is fine, so that is just a conversion error. Wonder if it is fixed yet? If not you should file an Online Pubs bug about it. I know some similar ones were fixed, but I don't see any immediate mention of that one (ref bugs 955 & 1060 for similar issues). | shall not be treated specially within a here- | document, except when the double-quote appears within "$()", "``", or | "${}"." The first $() is clear, that starts a new quoting context, just thinking about the 2nd almost makes my head explode, I have no idea what should be done with that one, or how it can be justified, the ${} case (since it is in a here doc, is already quoted, and hence the only defined quotes are after # ## % or %% operators - so that's what it must be referring to). But this (because it was all created because of limitations in the original (7th edn) Bourne Shell is all a huge mess. For a long time I was hoping that by making what happens with quotes inside a var expansion (the substring forms excepted) unspecified, and hence not something that applications can rely upon, would mean that eventually (perhaps way into the future) shells would be able to do things properly, rather than all follow the original shell because scripts break otherwise(the reason apparently that Korn switched ksh back from sane) when no-one is relying upon stuff like "${var:-"unquoted-text"}" any more. I have since realised that day can never come, as while we may eventually see an end to that kind of nonsense, we will never be able to rid ourselves of "${var-stuff}" where scripts are relying on "stuff" being quoted. So we can never make that go back to being unquoted, which would allow quotes to work properly in contexts like that. Very sad really. I'm rambling.... Never mind. | The question is how special [insert eye-roll emoji], and what | rules you follow. It seems like shells follow the double-quoting rules if | they follow any. For \ in a here-doc (unquoted end-delim) the double-quoting rules apply. That much is certain I think. (\n is certainly the 2 chars '\' 'n' and never a newline (a $'' cannot be embedded in a here doc, just as it cannot be in a double quoted string), and never just n (not even a quoted n)). Where a " is special in a here-doc (eg: inside a $() which is an unquestioned case) there is no question but that a \ makes the " just a char (and the \ goes away when it does that). The only real question here is just where/when the " is special in the here doc. Since there is no question that if "${foo}" appears in a here doc, and we have had foo=bar previously, then the result is "bar" and if \"${foo}\" appears instead, the result is \"bar\". All shells agree on those. There's also no question but that if foo='bar"' then ${foo%\"} in a here doc (or anywhere for that matter) produces "bar", there the quote is special, as it might have been going to be ${foo%"*"} where the quotes quote the '*' and make it a literal, not a "match anything"). Since the " is special there, the \ escapes it, and so we get a literal (quoted, not that it matters) double-quote. So that just leaves ${foo+"xyz"} Interpreting those double quote chars as quoting the xyz in a here doc, when, whatever they do, they definitely don't quote the xyz elswhere if (to emulate a here doc) this appears in a double quoted string "${foo+"xyz"}" whatever those "inner" quotes do (original Bourne shell had ${foo+ quoted, and the final }, and xyz unquoted), these days almost anything is possible, except for making xyz quoted (it would be without the inner double quotes). Anyway, making the quotes when they appear in a here doc become quoting chars, when they don't when not in a here doc, when in a here doc double quote chars normally aren't quoting chars, would be simply bizarre. If POSIX needs even more attention to this, then I guess that's what we need to do (but we know that as soon as we do that, the result will be that the meaning will become unspecified...) kre