Bug#613556: Why dash's local variable inherits its value from outter env?
weakish
Version: 0.5.5.1-7.4
Severity: normal
Given the following script:
f() {
local x
x='f'
g() {
local x
echo $x
}
g
}
f
pdksh, mksh and bash give the expected output, since x is not set in
g().
dash gives this 'f'
According to man dash:
When a variable is made local, it inherits the initial value and
exported and readonly flags from the variable with the same
name in the surrounding scope, if there is one.
Why does dash implement this feature? I guess sinec local is not specified
by POSIX, there isn't any history issues here.
-- System Information:
Debian Release: 6.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.32-5-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dash depends on:
ii debianutils 3.4 Miscellaneous utilities specific t
ii dpkg 1.15.8.10 Debian package management system
ii libc6 2.11.2-9 Embedded GNU C Library: Shared lib
dash recommends no packages.
dash suggests no packages.
-- debconf information:
* dash/sh: true
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Raphael Geissert
> According to man dash:
>
> When a variable is made local, it inherits the initial value and
> exported and readonly flags from the variable with the same
> name in the surrounding scope, if there is one.
>
> Why does dash implement this feature? I guess sinec local is not specified
> by POSIX, there isn't any history issues here.
Why do you consider it a bug? policy specifically says:
> * `local' to create a scoped variable must be supported, including
> listing multiple variables in a single local command and
> assigning a value to a variable at the same time as localizing
> it. `local' may or may not preserve the variable value from an
> outer scope if no assignment is present.
It's simply an unspecified behaviour, just initialize it to the empty value.
E.g. local x=
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Jonathan Nieder
tags 613556 + upstream wontfix
quit
Hi,
weakish wrote:
> Why does dash implement this feature? I guess sinec local is not specified
> by POSIX, there isn't any history issues here.
When there's no reason to behave otherwise, dash follows the
historical dash and ash behaviors, to give existing users a smooth
upgrade path. The original ash[1] follows the behavior you
described.
When a variable is made local, it inherits the
initial value and exported and readonly flags from
the variable with the same name in the surrounding
scope, if there is one. Otherwise, the variable is
initially unset.
The Austin Group is considering[2] specifying a "typeset" keyword
somewhat like local (but lexically scoped, maybe). If you have ideas
for what that should look like, feel free to get in touch with Eric
Blake and the Austin Group[3] list.
Kind regards,
Jonathan
[1] http://groups.google.com/group/comp.sources.unix/msg/2774e7653a8e6274
[2] http://thread.gmane.org/gmane.comp.shells.zsh.devel/21342
[3] http://www.opengroup.org/austin/
Jakukyo Friel
> When there's no reason to behave otherwise, dash follows the
> historical dash and ash behaviors, to give existing users a smooth
> upgrade path.
I see. Thanks for pointing out.
Jakukyo Friel
>
> Why do you consider it a bug? policy specifically says:
>> * `local' to create a scoped variable must be supported, including
>> listing multiple variables in a single local command and
>> assigning a value to a variable at the same time as localizing
>> it. `local' may or may not preserve the variable value from an
>> outer scope if no assignment is present.
Sorry for tag it as a bug before.
I just thought that dash's behavior is different from all other shell
I've encountered.
I now understood this behavior is from ash.