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 c...@case.edu http://tiswww.cwru.edu/~chet/
