Re: Bug with -o posix, local variables and assignment preceding builtins
On 2/7/10 8:33 PM, Crestez Dan Leonard wrote: We encountered a strange bug while working on bash-completion. I was originally only able to reproduce this through a fairly elaborate setup but Freddy Vulto fvu...@gmail.com found a tiny test case: set -o posix t() { local x BAR=a eval true } BAR=b; t; echo $BAR Bash documentation claims the following (section 6.11 point 23): See if the attached patch does the trick. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ *** ../bash-4.1-patched/variables.c 2009-11-03 14:13:58.0 -0500 --- variables.c 2010-02-08 17:36:18.0 -0500 *** *** 3809,3812 --- 3809,3817 if (tempvar_p (var) (posixly_correct || (var-attributes att_propagate))) { + /* Make sure we have a hash table to store the variable in while it is +being propagated down to the global variables table. Create one if +we have to */ + if ((vc_isfuncenv (shell_variables) || vc_istempenv (shell_variables)) shell_variables-table == 0) + shell_variables-table = hash_create (0); /* XXX - should we set v-context here? */ v = bind_variable_internal (var-name, value_cell (var), shell_variables-table, 0, 0);
Bug with -o posix, local variables and assignment preceding builtins
We encountered a strange bug while working on bash-completion. I was originally only able to reproduce this through a fairly elaborate setup but Freddy Vulto fvu...@gmail.com found a tiny test case: set -o posix t() { local x BAR=a eval true } BAR=b; t; echo $BAR Bash documentation claims the following (section 6.11 point 23): Assignment statements preceding posix special builtins persist in the shell environment after the builtin completes. The above example should always print a but with #local x commented it prints b. This is obviously wrong; the x variable is not even used. This can be reproduced on all versions of bash since at least bash-3.0 (probably on bash-2 as well). I also checked Debian's dash as an alternative posix-compliant shell and it always prints a as expected.
Re: Bug with -o posix, local variables and assignment preceding builtins
On Feb 7, 7:33 pm, Crestez Dan Leonard cdleon...@gmail.com wrote: We encountered a strange bug while working on bash-completion. I was originally only able to reproduce this through a fairly elaborate setup but Freddy Vulto fvu...@gmail.com found a tiny test case: set -o posix t() { local x BAR=a eval true } BAR=b; t; echo $BAR Bash documentation claims the following (section 6.11 point 23): Assignment statements preceding posix special builtins persist in the shell environment after the builtin completes. The above example should always print a but with #local x commented it prints b. This is obviously wrong; the x variable is not even used. This can be reproduced on all versions of bash since at least bash-3.0 (probably on bash-2 as well). I also checked Debian's dash as an alternative posix-compliant shell and it always prints a as expected. For reference, ksh93, busybox ash and zsh (with setopt posixbuiltins) print a