[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bash-5.2-rc3 available
Re: Bash-5.2-rc3 available
Wed, 31 Aug 2022 10:55:58 -0400
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.0
On 8/29/22 12:28 PM, Kerin Millar wrote:
For extglob to be arbitrarily enabled in either context is unexpected (and
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
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
For the benefit of anyone else reading, the following amounts to an error in
bash 5.1.16, as it should.
$ shopt extglob
$ [[ '' == $( : !() ) ]]
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
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 firstname.lastname@example.org http://tiswww.cwru.edu/~chet/