Re: Parameter expansion fails when assigning a local variable

[Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>]

On Mon, 22 Jun 2009, Herbert Xu wrote:

> Jesper Bengtsson <jesper.bengtsson@axis.com> 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