Re: Bash-5.1-beta available

[Robert Elz]

    Date:        Mon, 14 Sep 2020 12:04:02 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <6377c2e5-b496-8a80-2f86-d70a6f825b3f@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