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