On Mon, 17 Mar 2014, Cristian Ionescu-Idbohrn wrote:
>
> I just had a look att commit 109ee5d33694a03cda3424b4846584250832ba8e.
> IMO, to imitate bash behaviour isn't the right thing to do. It's a bug.
>
> Imitate dash behaviour instead.
>
> Refer to the test shell/ash_test/ash-misc/local1.tests.
> Upon entering function `f', `local a' makes a copy of the variable
> with the same name in the upper scope. `local a' should not
> implicitly `unset a'. Let the user decide what to do with variable
> 'a' (modify, unset, whatever).
I can now confirm the commit breaks several scripts based on these
assumptions:
1. all script variables are global...
2. ...unless declared local
3. a `local' declaration inherits the upper scope variable value
4. `local' modifications of the variable value are thrown away upon
`return' from the function
I consider the bash behaviour buggy.
Busybox ash is derived from dash. Holding to dash compatibility is,
IMO, TRT to do.
Several distributions (besides debian) adopted, for several reasons,
dash as the system shell. Using shell script code from such
distributions and running it under busybox ash will break.
The least probable damage can be achived by keeping the dash like
behaviour. Scripts specially written for bash assume `local'
variables are emptied and will set new variable values. Non-bash
scripts won't.
Denys,
Please revert that commit. IMO, that's the best of both worlds.
I recommed reading this paragraph (`man 1 bash') too:
BUGS
Cheers,
--
Cristian
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
