Re: Tutorial on zsh substitutions (Re: OPTARG not being set?)

[Sweth Chandramouli <sweth@xxxxxxxxxxxxxxxxxxxx>]

On Wed, Feb 03, 1999 at 12:56:50PM -0800, Bart Schaefer wrote:
> It's true that "the value of NAME" is a bad turn of phrase there.  A better
> way to describe it would be to say
> 
>     ${THING}
> 	When THING is a parameter name, the value of that parameter
> 	replaces THING.  When THING is another substitution expression,
> 	introduced by a leading '$', the value of that expression
> 	replaces THING.  All other processing specified by parameter
> 	substitution flags and modifiers is applied to the replacment,
> 	and the result is substituted for the entire expression.
> 
> The reason it's not like that is because (a) the manual was incrementally
> built up from documentation that predates nested substitutions, and (b)
> there was a desire not to "forward reference" flags, modifiers, and nested
> expression substitution until the simpler parameter-name-only cases were
> fully described.

	i think that these sorts of things could be explained by building
up from the simplest situations to the most complex, but that it would be
a lot easier if the concepts used in explaining them were built up in the
same way.  in the current docs, for example, the paramaters section comes
after the section on parameter expansion; it would seem to make more sense
to me to explain what a parameter is first, and set out the distinction
between names and values there, so that the terms can be more clearly used
when discussing expansion later on.
	this would, as you say, require people understanding a basic shell
grammar, but i notice that the info from the beginning of the zshmisc
manpage has been grouped together at the start of pws' online manpage 
under the heading "shell grammar".  while i have seen some people argue
that the manpages should be purely reference, without examples and such
things, i can't see how even those people would object to having the
concepts in the manpage build on one another, so that a person reading
through it for the first time would be able to follow what was going on
more easily.
	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.


[snip]
> Not exactly.  The difference is essentially that a name can never begin
> with a '$' character, so anything not beginning with '$' is a name that
> is used to look up a value, and anything that does begin with '$' is an
> expression that must be recursively interpreted to produce a value.
[snip]
> It is standard; what you're proposing amounts to an order-of-evaluation
> change.  That is, presently nested ${...} expressions are evaluated from
> the outside in, whereas you want them evaluated from the inside out.
	i see what you are saying here, but don't think that that explains
the actual behaviour.  my problem, i think, is that i am only able to discuss
it on a theoretical level based on the logic of operation association and
the effects that i observe; it may well be that what you describe _is_ what
is happening, but as it is, i don't see it.
	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?

> > > What Sven's new (P) flag does is force the value to be interpreted as a
> > > new name, the way the syntax misled you expect all along.  (Maybe the
> > > (P) flag ought to be ($), as in ${($)${bob}}.  Or more likely not.)
> > 	is this added in a dev version?  i can't find reference to it
> > in the 3.1.5 docs.
> 
> It was a patch just posted yesterday.  I didn't notice that this message
> was going to zsh-users, where some people wouldn't recognize the context.
	should this type of discussion be on zsh-workers instead?  i posted
it to zsh-users originally because i'm not on the workers list (since, as
i said above, i don't speak c and thus can't be much of a worker).
	(then again, considering that this is the second straight time you
and i have gotten bogged down in differences of opinion on how things in
the docs should be interpreted, maybe it isn't worthy of zsh-workers, either.)

> > > First, note that ${bob} substitutes to "joe".  ${(e)bob} is similar (but
> > > not identical) to $(echo ${bob}).  
> > 	how so?  according to the docs, (e) says to "[p]erform parameter
> > expansion, command substitution, and arithmetic expansion on the result."
> 
> Yes.  What that means is:
>     parameter expansion -- if the result looks like $param or ${...},
> 			   then substitute the value of that expression
>     command substitution -- if the result looks like $(command ...),
> 			    then evaluate command and substitute its output
>     arithmetic expansion -- if the result looks like $[expr], then
> 			    compute expr and substitute that result
> 
> That's "similar (but not identical) to" $(echo) because there really isn't
> any other syntax that expresses the same semantics -- the $(echo) is just
> as close as I could get to another way to explain it.
> 
> > 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, or that it somehow successfully expanded the string '${bob}'
(as opposed to the paramater bob).  i think i need to take a look at the
actual code to figure this out.

> > 	what is the difference between grave-accent command substitution,
> > $(...) command substitution, and eval's pseudo-command substitution?  it
> > looks like grave accents strip meta-char escapes, do param expansion, and 
> > then evaluate, while $(...) just does param expansion and then evaluates, 
> > and eval does param expansion, strips meta-char escapes, and then evaluates.
> 
> The main difference between "eval" and either of $(...) or `...` is that
> eval does not capture the output of the command that gets executed.
> 
> The main difference between `...` and either of $(...) or eval is that
> `...` is a quoting mechansism and gets parsed as one.  This causes the
> stripping of the backslash-escapes, and delays interpretation of other
> quoting mechanisms until the time of the evaluation.

	okay; this, at least, i get.

	thanks,
	sweth.

-- 
Sweth Chandramouli
IS Coordinator, The George Washington University
<sweth@xxxxxxx> / (202) 994 - 8521 (V) / (202) 994 - 0458 (F)
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html";>*</a>