Re: parse error in process substitution

[Peter Stephenson <pws@xxxxxxx>]

On Sun, 16 Nov 2008 13:51:27 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> schaefer[504] echo (<(echo|cat)|>(echo|cat))
> zsh: bad pattern: (/proc/self/fd/11|/proc/self/fd/13)
> schaefer[505] setopt nonomatch nocshnullglob
> schaefer[506] echo ${:-(<(echo|cat)|>(echo|cat))}
> (<(echo|cat)|>(echo|cat))
> schaefer[507] echo ${~:-(<(echo|cat)|>(echo|cat))}
> zsh: bad pattern: (<(echo|cat)|/proc/self/fd/12)
> zsh: command not found: echocat
> 
> Something still seems a bit odd there.  Where did "echocat" come from?

That's from >(echo|cat) which is getting parsed in some strange way.  It
shouldn't be being substituted at all.  I'll have to track that down.

> Also there's this -- first, zsh-4.2.0:
> 
> schaefer<501> echo $(<(echo cat))                    
> zsh: no such file or directory: (echo cat)
> 
> Now 4.3.9-dev-0 latest CVS:
> 
> schaefer[509] echo $(<(echo cat))                    
> zsh: permission denied: /proc/self/fd/10
> 
> I wonder if the $(< ....) form should also be special-cased?

Possibly, although you could also argue that if the contents look like
anything other than < followed by something that expands to a string it
should do that.  It depends what you mean by "look like".  You need to
quote metacharacters to be sure of getting a file name in general, of
course.

> } 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.
> 
> That also leaves unanswered the question of exactly what constitutes
> "a string" ... is the shell grammar really completely documented enough
> to make that discernible?

Not really.  Here it means something on the lines of "anything other than a
positional argument to a command or to array assignment".

> } > 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.
> 
> It used to produce a parse error.  I guess I was expecting that it
> would now produce either a "no such file" or a "no match" error
> because "/proc/self/fd/11what?" doesn't exist.

The reason I suggested it should perhaps still be a parse error is mostly
for the case of >>(...).  This won't work either but might give a more
confusing error message or use a different fd or something.  The latter
might happen with the input form, in fact.

-- 
Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070