Re: Bash 5 incorrectly overrides BASH_COMPAT env variable

[Chet Ramey]

On 4/18/19 10:46 AM, Marc-Antoine Perennou wrote:
> Hello,
> 
> After debugging why the unit tests of paludis (package manager from
> Gentoo and Exherbo) were failing with bash 5, I noticed a really weird
> behaviour which wasn't present in earlier versions of bash.
> 
> All the exemples I could find support the values we're currently
> checking for BASH_COMPAT in several environments (namely "3.2" and
> "4.2"). Everything works fine with bash 4, but with bash 5, this
> variable gets overridden and the new value is respectively "32" or
> "42" (notice the missing dot) when using the compat32 option.

This depends on the order the variables are processed. If BASHOPTS is
inherited from the environment, it gets processed after BASH_COMPAT.

The original bug that prompted the change is that bash-4.3 and bash-4.4
didn't modify or update BASH_COMPAT when setting one of the `compatNN'
options, which meant that BASH_COMPAT didn't reflect the actual
compatibility level if you used shopt. As you observed, setting BASH_COMPAT
sets the appropriate shopt option; the reverse should be true. That was
fixed over two years ago as one of the outcomes of this discussion:

http://lists.gnu.org/archive/html/bug-bash/2017-03/msg00002.html

So what happens is that since BASHOPTS is processed after BASH_COMPAT, if
includes the compatNN option, processing that option will set BASH_COMPAT
to NN, which I suppose is the canonical form because it reflects how bash
represents it internally. It doesn't check whether BASH_COMPAT has an
existing equivalent value, though I guess it could.

> A simple reproducer showing how... unexpected the results are:
> 
> keruspe@Lou ~ % bash
> keruspe@Lou ~ $ echo $BASHOPTS
> checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:globasciiranges:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
> keruspe@Lou ~ $ echo $BASH_COMPAT
> 
> keruspe@Lou ~ $ BASH_COMPAT=3.2 bash
> keruspe@Lou ~ $ echo $BASHOPTS # BASH_COMPAT=3.2 causes compat32 to be
> added here

Yes. They should always reflect the same thing to avoid the ambiguity that
existed before bash-5.0.

> checkwinsize:cmdhist:compat32:complete_fullquote:expand_aliases:extquote:force_fignore:globasciiranges:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
> keruspe@Lou ~ $ echo $BASH_COMPAT
> 3.2
> keruspe@Lou ~ $ export BASHOPTS

> keruspe@Lou ~ $ bash
> keruspe@Lou ~ $ echo $BASHOPTS
> checkwinsize:cmdhist:compat32:complete_fullquote:expand_aliases:extquote:force_fignore:globasciiranges:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
> keruspe@Lou ~ $ echo $BASH_COMPAT # launching a new bash with compat32
> in BASHOPTS has overriden the value
> 32

Yes, since BASHOPTS inherited from the environment is processed after
BASH_COMPAT.

> Is it intended that the value has no dot?

Both forms are accepted on assignment, but the internal form is an integer.
The  documentation didn't ever make it explicit that one form was preferred
over the other (they're equivalent). The intent of this change was to make
BASH_COMPAT reflect the shopt option currently in effect, and it uses the
internal form to do so.

What would you like to see happen? That when bash internally sets the value
it is to something that includes a dot? Bash to check whether BASH_COMPAT
already has an equivalent value before changing it? Something else?

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