I have a word of warning against improper use of local
in shell functions.
If you are using shell functions, you might want to declare some variables local to the shell function. That is good. The basic syntax for that is
local a b c
In some shells, you can also combine the local
declaration and
assignment, like this:
local foo=$1
local bar=$2
(The Debian policy even explicitly allows it.)
This is somewhat dangerous.
Bare shell assignment like
foo=$bar
does not perform word splitting, so the above is safe even if there
are spaces in $bar
. But the local
command does perform
word splitting (because it can take multiple arguments, as in the
first example), so the seemingly similar
local foo=$bar
is not safe.
This can be really confusing when you add local
to existing code and
it starts breaking.
You can avoid this, of course, by always quoting everything to like
local foo="$bar"
but overquoting isn't always desirable, because it can make code less readable when commands are nested, like
local foo="$(otherfunc "other arg")"
(Nesting is legal and works fine in this case, however.)
I suggest using local
only for declaring variables, and using
separate assignment statements. That way, all assignments are parsed
in the same way.
I think if "overquoting" would be used by every shell script developer, most scripts would contain far less security bugs.
ReplyDeleteLocal variables should indeed be declared and assigned independently. I needed help understanding this issue:
ReplyDeletehttp://www.zsh.org/mla/users/2013/msg00115.html
http://www.zsh.org/mla/users/2013/msg00116.html