Re: compat42 and compat41 behave incorrectly, compat41 not possible at all

[Grisha Levit]

These all appear to work correctly in the devel branch.

On Sun, May 22, 2016 at 2:52 PM, Gabriel Sharp <etherial_raine@outlook.com> wrote:

From: osirisgothra@hotmail.com
To: bug-bash@gnu.org,bash@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.]