bash-3.00.16 on IRIX incorrectly handles PAREN_ARITHMETIC
Configuration Information [Automatically generated, do not change]: Machine: mips OS: irix6.5 Compiler: cc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='mips' -DCONF_OSTYPE='irix6.5' -DCONF_MACHTYPE='mips-sgi-irix6.5' -DCONF_VENDOR='sgi' -DLOCALEDIR='/usr/bsd/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I./lib/intl -I/usr/include -c99 -O2 -n32 -mips4 -r12000 -apo -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r12000 -TENV:zeroinit_in_bss=ON -DEFAULT:platform=ip30 -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -woff 1174,1183,1552 -n32 -I/usr/include uname output: IRIX64 octane 6.5 07010238 IP30 Machine Type: mips-sgi-irix6.5 Bash Version: 3.0 Patch Level: 16 Release Status: release Description: PAREN_ARITHMETIC seems to be broken when bash-3.00 is compiled on IRIX: e.g. $ bash-2.05 -c 'A=$(( 2 + 3 )); echo $A' 5 $ bash-3.00 -c 'A=$(( 2 + 3 )); echo $A' 2: command not found And, infact, there may be some form of off-by-one error here: $ bash-3.00 -c 'A=$(x(2+3)); echo $A' 5 ... so it looks as if the character immediately following the initial opening bracket is dropped. Repeat-By: Compile bash on an IRIX machine using SGI's compiler suite (MIPSpro 7.4.3m, in this instance). Have yet to confirm whether bash compiled with GCC has the same problem... Cheers, Stuart ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash-3.x problems on IRIX
Configuration Information: Machine: mips OS: irix6.5 [6.5.30f, with MIPSpro 7.4.4m] Compiler: /usr/nekoware/bin/gcc [GCC-3.4.6] & /bin/cc [MIPSpro GCC Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='mips' -DCONF_OSTYPE='irix6.5' -DCONF_MACHTYPE='mips-sgi-irix6.5' -DCONF_VENDOR='sgi' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -mabi=n32 -mtune=mips4 -mfused-madd -mexplicit-relocs -mbranch-likely -O2 -fforce-addr -finline-functions -fno-keep-static-consts -fmove-all-movables -frename-registers -ftracer MIPSpro Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='mips' -DCONF_OSTYPE='irix6.5' -DCONF_MACHTYPE='mips-sgi-irix6.5' -DCONF_VENDOR='sgi' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O1 -n32 -mips4 -r14000 -apo -float_const -use_readonly_const -TARG:isa=mips4:platform=ip30:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -woff 1174,1183,1185,1552,3968 Compilation LDFLAGS: -Wl,-v -Wl,-s -Wl,-x -Wl,-n32 -Wl,-mips4 -Wl,-rdata_shared -Wl,-allow_jump_at_eop uname output: IRIX64 octane 6.5 07202013 IP30 Machine Type: mips-sgi-irix6.5 Bash Version: 3.2 Patch Level: 1 Release Status: release Description: Please see http://forums.nekochan.net/viewtopic.php?t=7547 for further discussion of these problems... The following problems exist, at the very least, in bash 3.1.16, 3.1.17, and 3.2.1 - I assume it affects the all bash-3.x releases. If bash is built with the SGI MIPSpro compilers then, now matter what other CFLAGS are in affect, the test suite fails in many ways (and one of the many issues this causes is what I describe in the first posts on the above forum). When bash is built with MIPSpro and "-O1" with any other combination of CFLAGS, the test suite mostly succeeds (the intl tests fail - but I assume this is because IRIX isn't UTF8-aware) - up to the printf tests. The output here is: gmake test ... run-intl warning: some of these tests will fail if you do not have UTF-8 warning: locales installed on your system. warning: please ignore any differences consisting only of white space 2c2 < 2 --- > 1 8,10c8,10 < aÃb < 000 141 303 142 < 003 --- > aéb > 000 141 303 251 142 > 004 ... run-printf - at which point the test-suite hangs (and reports "Error 130" if interrupted). Looking at the contents of /tmp/xx, the output up to the point of the failure was: 0.00 0.00 0.0 0.00 0.00 0.0 -INF -inf -INF -inf ... which means that the test which causes the hang is 'printf "%G\n" 4.2'. With GCC, the test-suite doesn't hang - but the results are: run-printf 61,74c61,74 < 0.00 < 0.00 < 0.0 < 0.00 < 0.00 < 0.0 < 0.00E+00 < 0.00e+00 < 0.0E+00 < 0.0e+00 < 0 < 0 < 0 < 0 --- > 4.20 > 4.20 > 4.2 > 4.20 > 4.20 > 4.2 > 4.20E+00 > 4.20e+00 > 4.2E+00 > 4.2e+00 > 4.2 > 4.2 >4.2 >4.2 81,82c81,82 < 0.00 < 0.00 --- > 115.00 > 115.00 .. so even with GCC printf doesn't work (but does always output a variant of "0", rather than negative infinity). Looking at the bash source, the hang is triggered from builtins/printf.def by the block starting at line 493. The problem might lie with the call to "PF (f, p);", where "PF" is a macro defined on line 90 - but I cannot see how this works. There's clearly some broken magic here if it causes MIPSpro to generate code which hangs, and GCC to produce code which always outputs a variant of "0"! Repeat-By: Attemping to build bash-3.x on IRIX with GCC or MIPSpro, regardless of CFLAGS. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Race in bash-4.3 'typeset'?
I have some code which evals a configuration file - but before doing so
attempts to validate the content. It does this by taking each potential
keyword from the file and then doing:
if typeset -p | grep -q "^declare -. ${var}$”; then
… to determine whether the keyword in question exists as a declared but unset
variable in the script.
However, I am seeing cases where the above incorrectly fails, or where
executing this line twice in immediate succession will fail on the first
invocation and then succeed on the second. This doesn’t happen every time, and
appears to be non-deterministic: running the entire script multiple times
sometimes results in an earlier failure, sometimes it continues succeeding for
many iterations more. Turning on xtrace or adding additional debug logging
does appear to prevent the problem from occurring, unfortunately.
Sometimes, with much less regularity, the above line actually fails with:
Re: Race in bash-4.3 'typeset'?
> On 25 Oct 2016, at 05:40, Martijn Dekker wrote:
>
> Op 25-10-16 om 00:42 schreef Stuart Shelton:
>> Failing this, is there any alternative to ‘typeset’ to list a
>> variable declared as local to a function but which has not yet been
>> assigned a value?
>
> Try simply testing the exit status of 'typeset -p' or 'declare -p'. If
> the variable is not declared, it exits unsuccessfully.
>
>if typeset -p "$var" >/dev/null 2>&1 && [[ ! -v $var ]]
>then ...
>
> As far as I can tell, this is not documented in 'help' or in the info
> page, by the way. Perhaps it should be.
>
> Also note that, while zsh and yash share this behaviour, ksh93 and
> mksh/pdksh do not. If you want to be compatible with all the shells that
> support 'typeset', you could do:
>
>if [ -n "$(typeset -p "$var" 2>/dev/null)" ] &&
> eval "[ -z \"\${var+s}\" ]"
>then ...
>
> which is slower because it uses a subshell.
>
> HTH,
>
> - M.
>
Hi Martijn,
Thanks for the suggestion!
However, it doesn’t appear to be able to detect local variables (is this
intentional or a bug?):
$ test() {
local testvar
echo “typeset test:"
typeset -p testvar && echo yes || echo no
echo “grep test:"
typeset -p | grep testvar
}
$ test
typeset test:
-bash: typeset: testvar: not found
no
grep test:
declare -- testvar
yes
Cheers,
Stuart
Re: Race in bash-4.3 'typeset'?
> On 25 Oct 2016, at 17:36, Eduardo Bustamante wrote: > > What version of bash are you using Stuart? typeset -p should work for > local variables too in any recent bash version. typeset omitting existing variables or failing and causing a SIGPIPE I’ve seen with Ubuntu 14.04 LTS’ bash-4.3.11(1). The immediately prior example (where variables declared local but unset in terms of value weren’t causing typeset to return successfully) was run on Ubuntu 16.10’s bash-4.3.46(1). This later version doesn’t seem to be affected by the apparently non-deterministic original problem, however. I’ve not seen any case where calling typeset again immediately after having called it and received an anomalous response doesn’t respond correctly - so my current solution is simply to invoke typeset twice… but the presence of this discrepancy is worrying. If this isn’t expected bash-4.3 behaviour, then it’s entirely possible that Canonical are doing something strange here, of course...
Re: Race in bash-4.3 'typeset'?
> On 25 Oct 2016, at 20:45, L. A. Walsh wrote:
> Stuart Shelton wrote:
>> I have some code which evals a configuration file - but before doing so
>> attempts to validate the content. It does this by taking each potential
>> keyword from the file and then doing:
>>
>> if typeset -p | grep -q "^declare -. ${var}$”; then
>>
>> … to determine whether the keyword in question exists as a declared but
>> unset variable in the script.
>>
> ---
> I don't think you can do that, primarily because
> you can't see the fact that something is declared but unset.
> "typeset -p" displays "attributes" AND "values". If the variables has
> no value, then how would it display that?
The cases appear, purely by inspection, to be:
Not declared: trivially, `typeset -p` doesn’t include the value;
Declared (even as local) but unassigned: `typeset -p` includes "declare --
varname";
Declared and assigned: `typeset -p` includes "declare -- varname=‘value’”
… although how much of this is by design and how much by chance I’m not sure ;)
> Also, in the above, what if the variable is declared as an
> integer and exported? Your grep-expression won't match, as
> it only allows for 1 flag. You might want to use grep -Pq and
> put a "+" after the "-."
This is a very good point - I only coded for the cases I’ve seen, and the
single-flag situation covers this. I will update it, though, to reflect the
wider range of possible values...
> Also, what is ${var} supposed to contain? I'm guessing that var
> isn't your variable you are testing for but maybe the name of the
> var?
Yes, in this case ‘var’ is a loop-variable which cycles through each keyword in
the configuration file to be validated.
> I've had that confusion in some scripts where I had functions taking
> arrays of 'var' -- which for some meant arrays of values, but in
> other cases I needed the names of the vars that contained those values.
> I ended up with a weak rule to try to always append "nam[e]" or "str[ing]"
> to things that were to be interpreted as names or strings, then
> using nothing, or 'ptr' or 'ref' on the end to indicate it was
> a reference to the value, like:
>
> var=33
> varname=var
> echo "name of var=$varname, value=$var"
Also a very good point :)
>> However, I am seeing cases where the above incorrectly fails, or where
>> executing this line twice in immediate succession will fail on the first
>> invocation and then succeed on the second.
>
> Is it being assigned a value between invokations?
Nope - literally run the same command twice in immediate succession, and the
output differs, with the first omitting any value or causing a SIGPIPE to be
generated, and the second with the expected value which reflects the
environment. The second call always appears to do the right thing, though -
and given that a sleep before (or between, although the second case has always
succeeded) the command appears to have no effect, I wonder whether there’s some
counter or flag not being updated correctly?
