Re: Bash-5.1-beta available
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, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Do a readline function execution inside bash
On 9/14/20 9:57 PM, Budi wrote: > simply run a readline function among lines codes of bash script such a > menu-complete, or menu-complete repeated thrice, or etc etc In this model, where would readline get its data? Readline functions operate on pieces of an input line, or an entire input line, so where would this line come from? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bash-5.1-beta available
Date:Tue, 15 Sep 2020 11:47:58 -0400
From:Chet Ramey
Message-ID:
| This wouldn't be the first time the standard relied on readers
| drawing an inference that's not explicit.
No, it isn't. It is really hard to avoid that however, as quite often
when the text is written, everyone simply assumes that the meaning is
obvious. Same with the Reply-To discussion happening on the austin list
(where it doesn't really belong, and wouldn't have happened if they
hadn't butchered the list) where the ancient text in RFC822 has been
read to justify behaviour that makes no sense, and was never intended.
(And I really hope that you personally are paying attention!)
| when no-one is relying
| > upon stuff like
| > "${var:-"unquoted-text"}"
| > any more.
|
| I don't think you can rely on this right now.
No you can't. The standard says (or is going to say) it is unspecified,
and some implementations have started doing bizarre things. It certainly
never documented the weird 7th edn sh (and everything else in the early days)
behaviour.
My point was that even though this usage has become obsolete, we
can't fix the quoting anyway, because of "${var:-text that is quoted}"
| The last time we talked about the "even number" sentence, we all just
| hand-waved it away by characterizing it as an "application requirement,"
Yes, but there's nothing else it can be, even with:
| even though there's no mention of "the application shall ensure" there.
as if there's a requirement, then either the implementation or the
application (or both) needs to be bound by it. Here the implementation
can't ensure there are an even number of quotes, it isn't writing the
text, so this has to be directed at the application.
The implementation can error out if it wants if it detects the error
(I don't think anyone does) but the error is that of the application.
It must be.
| It's all just a mess,
It is that, and really all prompted by pdp-11 address space limitations!
| and the standard is avoiding saying anything definitive.
It has little choice, it isn't a legislature. But at least when things
are made unspecified it gives us implementors (or maintainers more in my
case) an opportunity to agree what interpretation makes most sense, and
all agree to implement that. When we can actually make that happen we
might eventually end up in a situation where a later standard rev might
be able to specify things again.
| 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.
Actually I disagree (and not because you used backticks as opening quotes
there).
There's no issue in something like
${var-"}"}
in that one there is an enclosed quoted string (whether double or
single quoted - backslash quoted works too). but in
"${var-"}"}"
there is no enclosed quoted string, the (lexically) second " char either
closes the quoted string opened by the first, or has unspecified behaviour,
but it isn't creating a new quoted string. Nor would it be using '', which
aren't special at all inside a "" string. The only safe way to quote that
(intended to be literal) '}' is using \ quoting, as that does work in a
double quoted string, and somewhere the standard, or some interpretation,
does say that, I remember reading it. (I think it glosses over the \
escaping rules in "" strings though, the '}' needs to be added to the list
of chars that \ escapes, and I don't think that is ever explicitly done, it
is simply implied that it ought to work that way).
Aside: for readers following along, who can't really believe some of this,
note that the original Bourne shell would happily allow
"${var-*"*}
where (when var is unset) the result is a list of all files starting with
a (literal) '*'. Not something one can rely upon any more (fortunately).
That is, despite this being useful functionally, the closest we can
currently do is
${var-\**}
(using any form of quoting you like for the first '*'). But this suffers
from leaving the expansion of var (when var is set) unquoted, whereas
the old form did not. There is currently no safe simple way to have a quoted
var expansion with an unquoted alternative to use if the var is unset.
| The current version of the standard makes that clear, shells have
| implemented it that way,
Some shells. Based upon a mis-reading I believe. It isn't the
way you're reading it.
| and I'm sure there are scripts somewhere that rely on it.
There are scripts that rely on all kinds of bizarre things, sometimes
we simply have to break them. Otherwise we can't even fix bugs, because
someone might be relying upon the buggy behaviour.
kre
