[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: Assigning to multiple variables on same line
From:       Mike Frysinger <vapier () gentoo ! org>
Date:       2009-08-13 20:27:04
Message-ID: 200908131627.05946.vapier () gentoo ! org
[Download RAW message or body]


On Thursday 13 August 2009 11:43:11 Chet Ramey wrote:
> > On Thu, Aug 13, 2009 at 02:45:51AM -0400, Mike Frysinger wrote:
> > > i dont think word expansion occurs first, otherwise wouldnt this break:
> > > foo() {
> > > 	unset b c
> > > 	f="a b="
> > > 	local a=$f c=
> >
> > As I understand it, this is what happens:
> >
> > 1) The parser separates out the tokens that constitute the command. 
> > These are `local', `a=$f', and `c='.  The meaning of each token is
> > determined.
> >
> > 2) Parameter expansion is performed on the $f.  But this can't create a
> >    new token.  It's too late for that.  The whitespace becomes part of
> >    the second token.  (If you wanted a new token, you'd have to use
> > eval.)
>
> Close.  Bash treats assignment statement arguments to certain builtins
> (typeset/declare/export/readonly/local) differently by inhibiting word
> splitting after expansion, so the word expansions performed are closer
> to those performed on an assignment statement.  This has been
> controversial, but reduces user surprise.

i for one highly appreciate this behavior.  i complain frequently that dash 
does this for some builtins, but not all.  and they seemingly use the same 
argument to justify both behaviors ...
-mike

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic