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