Bug with -o posix, local variables and assignment preceding builtins
Crestez Dan Leonard
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.
DennisW
For reference, ksh93, busybox ash and zsh (with setopt posixbuiltins)
print "a"
Chet Ramey
> 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, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/
Crestez Dan Leonard
> 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
my initial testing setup.