Re: Bash-5.1-beta available

[Robert Elz]

    Date:        Tue, 15 Sep 2020 11:47:58 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <f42ac948-4c08-555a-3355-9edf929e55f3@case.edu>


  | 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