Re: Bash-5.2-rc3 available

[Chet Ramey]

On 8/29/22 12:28 PM, Kerin Millar wrote:

> > > For extglob to be arbitrarily enabled in either context is unexpected (and 
> > > undesirable).
> >
> > The conditional command behavior is compatible with ksh93, and has been
> > this way for nearly twenty years. It's documented to behave that way. One
> > would think people are used to it by now.
>
> I am aware of how the == and != operators work, and that the pattern on the 
> right hand side is always treated as an extglob in the shell performing the 
> test [*]. I don't see what bearing that has on my report or its wording.

OK. You wrote "either context" above. There are two contexts in which 
extglob is enabled internally: conditional commands and (now) command
substitutions. The former has been the case for a long time; the latter
is new.

How am I supposed to interpret "either context?" A reasonable person could
assume that you're objecting to established behavior.

 Might I enquire as to what it is that I am supposed to be used to on 
account of the passage of those twenty years? Certainly not for a command 
substitution on the right hand-side of the == operator to implicitly 
perform the equivalent of shopt -s extglob within the implied subshell 
without so much as a by-your-leave on the part of the programmer, much less 
doing so in the shell that specified the command substitution.


Wow, that was quite a sentence. In any event, you should report it, as you
did.

> For the benefit of anyone else reading, the following amounts to an error in 
> bash 5.1.16, as it should.
>
> $ shopt extglob
> extglob         off
> $ [[ '' == $( : !() ) ]]
> bash: command substitution: line 3: syntax error near unexpected token `('
> bash: command substitution: line 3: ` : !() )'

It will produce exactly the same error in bash-5.2. On the other hand,
there are valid constructs that bash-5.1 did not handle, and no amount of
coercion could make it do so. I included one in a previous message thread.

The ad-hoc comsub parser in previous versions didn't understand extglob
patterns at all, period, whether or not extglob was enabled. That resulted
in it accepting bad code, invalid constructs that later resulted in errors,
and valid patterns that were later accepted when the command was executed,
as in a shell function definition. The current compatibility mode behavior
is a concession to that previous reality. The problem is that neither you
nor I know how many instances exist.

In this case, the backwards compatibility setting doesn't matter, of course --
parsing the word on the rhs of the ==/!= operator forces extglob on, and
the command substitution parsing inherits that. That is not new behavior.


> I understand that you are striving to do right by a majority of your users at all times. The reported issue was a consequence of a regression in a late-stage release candidate introduced by a new backward compatibility feature that I had not elected to enable. 

Yes, it's good that you reported it. There will probably be another release
candidate as a result.

> > I understand from Sam James that Gentoo globally forces the compatibility
> > mode to 5.0. That, too, is a choice.
>
> Yes, that's right - subject to the "EAPI" level defined by a given ebuild.

So your users, or those who prepare ebuilds, have made a decision to set
that. One of the consequences of that choice is this undesirable (as you
put it) behavior of having extglob enabled during command substitution
parsing.

 Yet, I can't shake the feeling I had from the outset that, in this 
particular instance, the compromise may simply not be worth it.

We'll see. There may not be any impact. On the other hand, I can't shake my
feeling that there are a lot of scripts out there doing this because it
"just worked" before.


--
``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/