bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bash-5.1-beta available


From: Chet Ramey
Subject: Re: Bash-5.1-beta available
Date: Wed, 16 Sep 2020 11:35:41 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 9/15/20 2:09 PM, Robert Elz wrote:
>     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.

That's what gives the impression that the standards committees are a
private club. Well, that and the "it was a bad idea in 1988, so it's
a good idea now!"

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

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

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

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.

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

That's the issue. Even if it's an application requirement, the shell
implementation still has to do some enforcement, and that means checking
that embedded quotes are properly paired.


   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.

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

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

But that doesn't matter. The burden is still on the implementation to check
it and react accordingly. Previous versions of the standard required it.

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

It's a typographical convention of many years.

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

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. It's unclear whether or not the standard really means the
quotes within the braces constitute a separate quoted string, but there is
broad consensus that the inner pair of double quotes prevent the brace from
ending the parameter expansion.


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

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.


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

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}'.


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

I agree with this in general, and have used it myself. There just needs to
be a compelling reason to change and break backwards compatibility. I
haven't seen one.

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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]