Re: Bash-5.1-beta available

[Robert Elz]

    Date:        Wed, 16 Sep 2020 11:35:41 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <210592e5-f42c-32ee-7c85-9418d3e2993c@case.edu>

  | That's what gives the impression that the standards committees are a
  | private club.

This one isn't confined to the standards industry, it exists everywhere.
At a particular time, in a particular community, there tends to be a
common understanding of all kinds of things.  Different time, different
community, and that understanding just isn't there any more.

  | Well, that and the "it was a bad idea in 1988, so it's
  | a good idea now!"

That one is a different problem.

  | I read it all. The hills are littered with bodies.

Would be nice if you could delete the Reply-To your messages all
carry, since it is (every time I have seen anyway) the same as the
>From it is useless if intended as a From replacement, and I kind of
doubt that you always want to request that no-one reply to the list.

  | The problem is the standard has changed over the years, and now we all
  | have compatibility issues dealing with past attempts to implement what
  | ended up being a moving target.

Yes, that is a problem.  Partly caused by trying to implement the
standard, instead of implementing what is right, and then making sure
the standard says what is implemented.

  | That's the issue. Even if it's an application requirement, the shell
  | implementation still has to do some enforcement,

No, it doesn't.  When applications violate the requirements upon them
what the implementation does is always unspecified.   Detecting and
reporting the error is nice, when it can be done (particularly when it
needs to be detected, and there's nothing else better to do) but other
things are possible, including dreaming up some new meaning for it.

  | Of course it can. It can check and throw an error if desired.

That isn't ensuring that there are an even number of quotes, it is
objecting when there aren't.  The two are related, but are not the
same thing.

  | > Actually I disagree (and not because you used backticks as opening quotes
  | > there).
  |
  | It's a typographical convention of many years.

Yes, I assumed, that was irrelevant.


  | It might be unspecified in the current draft of the upcoming version of the
  | standard, or at some time in the future, but even the currently published
  | version of the standard talks about embedded quoted strings without
  | qualification.

Yes, I agree, but it has to be an embedded quoted string, not just a
string that happens to contain quote characters.

Eg:
        foo'bar'bletch
contains an embedded quoted string.
        "foo'bar'bletch"
does not (it is a quoted string, it does not contain an embedded one).
The single quotes are simply characters.

  | The current standard says
  |
  | "an even number of unescaped double-quotes or single-quotes, if any, shall
  | occur. A preceding <backslash> character shall be used to escape a literal
  | '{' or '}'"
  |
  | so it's there.

OK, though I'd say half there, that text is much improved in the forthcoming
version.


  | Given this script:
  |
  | foo=bar
  | echo "${foo+"x}z"}"
  |
  | every modern shell I tested produces
  |
  | x}z
  |
  | where the historical Bourne shell would give `xz}'.

All except bosh in the tests I ran (bosh seems to go into a cpu loop).
I'm just not sure this is correct according to the current standard.
Which is probably why it doesn't really matter, as this is clearly going
to be unspecified in the future.

But to go back to the original issue, in a here-doc, the " is always just
a character, it is never special, and hence a \" combination in a here doc
(except in those cases where a new quoting context is established - which
it isn't in a ${foo+word} expansion - never has been) should always
generate \"

kre