[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