Re: Bash-5.1-beta available

[Chet Ramey]

On 9/14/20 2:56 PM, Robert Elz wrote:

>   | "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).

Plausible, perhaps likely. But it's not clear. This wouldn't be the first
time the standard relied on readers drawing an inference that's not
explicit.


> 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 don't think you can rely on this right now. The only thing the currently-
published version of the standard dares to say about that is "an even
number of unescaped double quotes shall occur" and the "matching closing
brace shall be determined by ... skipping over enclosed quoted strings ...".

The last time we talked about the "even number" sentence, we all just
hand-waved it away by characterizing it as an "application requirement,"
even though there's no mention of "the application shall ensure" there.
The upcoming issue8 makes it explicitly unspecified, but the damage is
already done.

The situation with the "matching closing brace" text isn't any better.
The word "enclosed" is gone in the current draft, but "quoted string"
is still there, and we still have shells implementing the current
standard's language.

It's all just a mess, and the standard is avoiding saying anything definitive.


> I'm rambling....   Never mind.

:-)


> 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).

The xyz is semi-quoted, because no matter what else the inner quotes might
do, they are supposed to prevent recognizing the closing brace. If it were
not `xyz' but `x}z', the inner quotes are supposed to `protect' the brace
there. The current version of the standard makes that clear, shells have
implemented it that way, and I'm sure there are scripts somewhere that rely
on it.

> 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...)

There's no meaning now! At least if it's explicitly unspecified we can at
some point -- maybe -- specify something. And who knows? The discussion
may prove illuminating.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/