Re: parse error in process substitution

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

Bart Schaefer wrote:
> } ">" and "<" never used to need quoting when used inside parentheses or
> } parameter substitutions, so to keep this I've had to forbid the use of
> } <(...) and >(...) in such places.
> 
> Can you give examples of a couple of "such places"?  I thought I knew
> what you meant, but when I try what I thought should fail, it doesn't.

I think they're more specialised than I previously assumed.  The one I
was particularly aiming at was

% var="<foo><bar>"
% print ${var##<([a-z]##|)>}
<bar>

(which still works) which is similar to what's used in Test/comptest.
This is probably due to the comment quoted below.

> For example:
> 
> schaefer[514] echo x<(echo foo)y
> x/proc/self/fd/11y
> schaefer[515] echo (<(echo foo)|>(echo bar))
> bar
> zsh: bad pattern: (/proc/self/fd/11|/proc/self/fd/13)
> 
> OK, so it's a bad pattern, but the substitutions still happened.

Your're right, I've claimed more than what's actually the case.  I think
I've achieved what I was mainly aiming at, i.e. allowing anything that
was previously valid still to be so (cases like this previously reported
a parse error at the "<" or ">"), but it doesn't correspond to what I
said in the documentation.

The key point is this comment in the lexical analyser:

   When called from gettok(), with sub = 0, we have already identified
   any interesting initial character and want to get the rest of
   what we now know is a string.  However, the string may still include
   metacharacters and potentially substitutions.
 
   When called from parse_subst_string() with sub = 1, we are not
   fully parsing a command line, merely tokenizing a string.
   In this case we always add characters to the parsed string
   unless there is a parse error.

I've allowed <(...) and >(...) to be expanded when sub = 0, but not when
sub = 1, which is what happened before except only if the expansions
were complete arguments, so I need to find a better description.
"When parsing a string" is close but perhaps doesn't quite express it.

(It's not at all obvious why you would ever use the substitutions like
that but I'm aiming at consistency rather than imposing arbitrary
limitations on cases I don't feel like handling.)

> } Parsing of the contents of these expressions is done rather more simply
> } than for $(...) expressions.  I don't really know if there's any mileage
> } in making parsing of process substitutions more similar (inside the
> } parentheses only, the context dependence will have to remain
> } different).
>
> Is the $(...) one perhaps more complex because it has to work inside
> double-quotes and therefore with possible quote nesting?  Otherwise
> I would think that the simplest parse that doesn't fail on convoluted
> cases is the one that both of them should be using.  

Yes, that may well be the case, as occurred to me over the weekend, so I
don't need to do anything cleverer since I don't want < and > to become
special in double quotes.

> One last item ... perhaps you can explain what's going on here:
> 
> schaefer[518] cat <<(echo foo)what?
> foo
> schaefer[519]
> 
> I'm not sure exactly what I expected, but that wasn't it.

I haven't changed any of the parsing for redirections: they are handled
separately.  So it looks like this is now inconsistent and needs fixing.

Again, it's not clear why you would ever do that.  I suppose since the
file name produced by the substitution is essentially opaque to the user
you could argue it should report an error in this and similar
cases---otherwise, it looks like the case "when parsing a string", with
the complication that globs here trigger the multio syntax which isn't
relevant to the case of process substitution.  An error would probably
be simpler.

-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/