bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

compat42 and compat41 behave incorrectly, compat41 not possible at all


From: Gabriel Sharp
Subject: compat42 and compat41 behave incorrectly, compat41 not possible at all
Date: Sun, 22 May 2016 14:52:42 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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.]


reply via email to

[Prev in Thread] Current Thread [Next in Thread]