On Mon, 22 Jun 2009, Herbert Xu wrote:
> Jesper Bengtsson <[email protected]> wrote:
> >
> > I've found a problem with expanding $...@.
> > If I declare a local variable and assigns the expanded positional
> > parameters:
> > local v="$@"
> > It fails with something like:
> > local: 20: \/: bad variable name
>
> This is expected behaviour.
Hmm... Why is it so? Because it's the only "natural" expectation?
> local is just like any other utility
Utility? Not built-in? Documentation refers to it as command. Same
thing?
> in how it handled parameters. So "$@" will have been split before
> it reaches local. To get what you want, you should use "$*".
But wait a second. Shouldn't quotes '"' around $@ protect the whole $...@?
It does so in different other context. Why not here?
> > I've tried this on dash 0.5.5.1 and 0.5.3 and both fail in the same way.
> > I've also tried on bash and ash (Busybox) and both handles declaration
> > and assignment on one line.
>
> Bash and older versions of dash (like the one in Busybox) has a hack
Hack. Is that a hack? It is not expected behaviour. It's a hack?
Even newer/recent/latest versions of (busybox) ash have that "hack".
And dash claims to be the only POSIX "true" implementation?
> that disables field splitting for local and certain other
> commands. This is not guaranteed by POSIX.
Sure. That's what it looks like. POSIX doesn't even mention it, does it?
Still. Quotes around $@ should protect it, shouldn't it?
local v="$@"
should expand to:
v="'arg1' 'arg2' ..."
shouldn't it?
There's som parallel unnatural behaviour I noticed:
local var=$(some forked thing here)
$(...)
^^ ^ doesn't seem to protect the resulting string. There seems to be a
difference between:
local h=$(grep --help)
and:
local h="$(grep --help)"
Can anything motivate that? Is that POSIX too?
Cheers,
--
Cristian
--
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
