From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Bart Schaefer" <schaefer@brasslantern.com>
Message-Id: <990203194802.ZM14002@candle.brasslantern.com>
Date: Wed, 3 Feb 1999 19:48:02 -0800
To: Sweth Chandramouli <sweth@astaroth.nit.gwu.edu>, zsh-users@math.gatech.edu
Subject: Re: Tutorial on zsh substitutions (Re: OPTARG not being set?)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: <zsh-users@sunsite.auc.dk> 2078

On Feb 3,  8:16pm, Sweth Chandramouli wrote:
> Subject: Re: Tutorial on zsh substitutions (Re: OPTARG not being set?)
> On Wed, Feb 03, 1999 at 12:56:50PM -0800, Bart Schaefer wrote:
> 	all of that said, it would be a pretty big task to reorganize all
> of the docs that way; if there aren't any objections, i would be willing
> to at least give it a shot.

You'd need to get the pws-6 release plus the four or five doc changes that
have been posted since.  You need to get the yodl suite and learn the yodl
language.  And then you'd need to cope with the ongoing changes to zsh; the
pace of development right now is the fastest it has been in several years.

In short, I don't think anybody would object, but this might not be the best
time to do it (except maybe for the learning yodl part).

> 	even though i don't speak c, i think i might get a better idea of
> what is going on if i could see what is being parsed when in the code 
> itself.  could you (or someone else) give me a pointer to which file, and
> where in that file, this expansion is processed?

It's the function singsub() in the file Src/subst.c; nested substitutions
are handled by a call to multsub().  Good luck understanding it.

> 	should this type of discussion be on zsh-workers instead?

No; it's just that the volume of traffic on zsh-workers has been very high
lately, and the list forwarding arrangement at the new host site makes it
less obvious that the list originated on zsh-users when delivering to those
of us who get it through zsh-workers.

> > > i originally thought that this meant that ${(e)${bob}} would parse to
> > > ${(e)joe}, and then perform parameter expansion on ${joe}
> > 
> > No.  "The result" is just "joe".  Outside in, not inside out -- the outer
> > ${...} is already "used up" by the time the (e) is applied.  Get it?
> 	not really.  as i said above, i see what you are saying, but the
> way i interpret it, that would mean that either the outer ${...} was turned
> into a no-op

That pretty much is what happens.  The outer ${...} "queues up" all the
flag and modifier manipulations that need to happen and then gives control
over to the inner ${...} or $(...).  When that finally comes back, all the
flags and modifiers are applied, with (e) always applied last of all, and
then the resulting text is returned.