|
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
* 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.] |
[Prev in Thread] | Current Thread | [Next in Thread] |