These all appear to work correctly in the devel branch. On Sun, May 22, 2016 at 2:52 PM, Gabriel Sharp <etherial_ra...@outlook.com> wrote:
> From: osirisgot...@hotmail.com > To: bug-bash@gnu.org,b...@packages.debian.org > Subject: compat42 and compat41 behave incorrectly, compat41 not possible > at all > > compat42 and compat41 shell options are set incorrectly when set via > BASH_COMPAT > > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib > -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -Wall > uname output: Linux larnica 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 > 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > Description: > when setting BASH_COMPAT to the documented values of '4.2', '42', > '4.1', and '41' the > shell responds incorrectly by setting the incorrect shell option, > see the repeat-by for > a table to clearly see what is going on. Please note problematic > values are listed along > with a SINGLE working value for contrast purposes, the other unlisted > values work as expected. > > > Repeat-By: > TABLE 1 - BASH_COMPAT <-> shell options (shopt) relationships > > > BASH_COMPAT shopt result > expected shopt error? notes > > 3.1 compat31 compat31 NO > 31 compat31 compat31 NO > 3.2 compat32 compat32 NO > 32 compat32 compat32 NO > 40 compat40 compat40 NO > 4.0 compat40 compat40 NO > 4.2 NONE compat42 YES > 42 NONE compat42 YES > 4.1 compat41, compat41 YES (1/2**) > 41 compat41, compat41 YES (1/2**) > <unset or ""> > NONE NONE NO > > * all values are set EXACTLY as shown unless between arrowed brackets > <> > ** when two options get set, one is correct, the other is not because > more than one would contradict it's purpose. > > 1) start a bash shell with 'bash --norc' to ensure no/minimal outside > influences > 2) type 'BASH_COMPAT=<value>; shopt | grep compat' where the > <value> is one of the entries from the above table > 3) press ENTER to set and observe the effects of the variable being > sete > > Fix: > Not too sure but I can guess as a programmer that there is some kind > of fence post > error OR bit-logic error. I dont have time to go through the source > myself, so I hope > this is enough info. No coredump because no crash actually results > from this. > > PS: Not sure if this is intended or not, but when errexit is set, and > an invalid BASH_COMPAT > value is assigned; the error message is displayed, but $? is unchanged > as if no error was > observed, and as a result, errexit does not cause an exit. I was in a > position where I needed > this to happen, and it seemed that because of that, it is a little > pointless to even have BASH_COMPAT > if the error doesn't even communicate to the script's environment in > any way (except 'catching' output, which > may more may not work if redirections are in effect). > > Sorry if this was not a bug or problem and I had missed some > documentation -- please let me know where it is > so this documentation may become more informative (info or man). > > > > [Description of how to fix the problem. If you don't know a > fix for the problem, don't include this section.] > >
