Hi Herbert,
Would you be open to the idea of making dash's "local" work more
like the scope modifier that its name implies than like a separate
command in which assignments have different semantics?
To be clear, "local" is not standardized, so the change I'm advocating
would not be a bug fix ;-) However, it would make dash align with
bash and zsh, and imho, with common sense.
Here's what I mean:
Currently, variable assignments like var=$other_var
require no quotes around the RHS. That's covered by POSIX.
However, when you want to reduce the scope of that "var"
and use "local var=$other_var", you have subtly changed
semantics in dash, (but not with bash or zsh).
The local-using assignment appears to work, but evokes
a "bad variable name" warning and causes failure:
This works fine:
$ dash -c 'f() { b="1 1"; z=$b; echo "$z"; }; f'
1 1
However with "local" on the latter assignment, it fails:
$ dash -c 'f() { b="1 1"; local z=$b; echo "$z"; }; f'
local: 1: 1: bad variable name
1
[Exit 1]
Regards,
Jim
PS, this started when I noticed FreeBSD 8.1's /bin/sh doing something
odd with local and IFS, and on that basis decided to eliminate it from
the list of candidate shells used for running coreutils tests. Then I
noticed that dash did the same thing. I don't want to disqualify dash,
so am hoping to minimize fragmentation in how shells treat "local".
Actually, here's a much better way to demonstrate the problem:
(this is using 016b529d2b114efc6cd91fe4e3e4767ba615870a, the latest
from the dash.git repository):
$ ./dash -c 'f() { b="1 x=3"; local z=$b; echo "z=<$z> x=<$x>"; }; f'
z=<1> x=<3>
That makes it clear that the part of $b's value after the first token
is being treated as additional arguments to "local".
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
