[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [3.0.13] declare -a a=('$0')
From: |
Chet Ramey |
Subject: |
Re: [3.0.13] declare -a a=('$0') |
Date: |
Wed, 15 Sep 2004 16:46:04 -0400 |
> > > declare seems to evaluate its arguments:
> >
> > It does. The process is actually very regular.
> >
> > Assignment statements (at least compound assignment statements)
> > appearing
> > as arguments to `assignment builtins' are parsed specially -- as a
> > single
> > word. The word becomes one of the arguments to `declare', but marked as
> > an assignment.
> >
> > Each argument to declare is expanded. The words marked as assignments
> > (since `declare' is an `assignment builtin') are expanded exactly as
> > assignments preceding commands.
>
> That's not clear to me.
You stopped in the middle. This is what happens before declare is invoked.
Your example supports this.
> bash-3.00$ env -i /usr/local/bin/bash -c 'a=(1 \$PATH) env'
> a=(1 $PATH)
> PWD=/export/home/chazelas
> SHLVL=1
> _=/bin/env
>
> (here, $PATH was not expanded). But that makes no sense to pass
> an array as an environment variable of a command.
True enough, though some versions of ksh try (though not using this format).
caleb.INS.CWRU.Edu(2)$ cat x15
zzz=(1 2)
export zzz
printenv zzz
caleb.INS.CWRU.Edu(2)$ ksh93 ./x15
1
> > When declare is run, it re-parses the arguments that appear to be
> > compound
> > assignments. It does the expansion, because at this point there's no
> > way
> > to tell whether or not the original assignment was quoted.
>
> I'd think that's why it shouldn't be *parsed* as a command (ksh,
> whose "type" lies when it pretends "typeset" is a "builtin"). Or
> that it should be parsed as any other command and therefore that
> array assignments are made impossible.
>
> > declare has to do some reparsing, since it only gets a single argument
> > and
> > has to somehow split it and understand [index]=value. It uses exactly
> > the
> > same code as compound assignments preceding commands.
>
> What do you mean by "compound assignments preceding commands"?
It's posix-speak. Assignment statements are referred to as preceding
commands, even if there are no `command words' (which are optional).
In this case, compound assignments are not allowed preceding non-empty
commands.
> Still, that doesn't make much sense to have two different
> parsings for
>
> array=(...)
> and
> declare -a array=(...)
Agreed, it should be cleaner than it is. I'll have to see if there's
a clean way to avoid the double-expansion, but only for compound array
assignments. And without breaking backward compatibility too badly.
> (especially when it's not documented and not compatible between
> versions of bash).
You want bug-for-bug compatibility? I should go home now.
> The simplest, to my mind is not to allow array assignment with
> "declare".
Simple, but not backwards-compatible.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live...Laugh...Love
Chet Ramey, ITS, CWRU chet@po.cwru.edu http://tiswww.tis.cwru.edu/~chet/