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. 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 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 Is it intended that the value has no dot? Regards, Marc-Antoine
