Re: parse error in process substitution

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 13,  9:00pm, Peter Stephenson wrote:
} 
} A non-initial = usually isn't handled specially, and raw parentheses
} (i.e. without a disambiguating character in front) are somewhat
} overworked in zsh, so I couldn't make =(...) special anywhere except at
} the start of an argument.

I think this is OK, as it's already ambiguous with respect to array
assignment syntax when not at the start of a word.

I"m glad to see that var==(cmd) still assigns a file name to $var.

} ">" 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.
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.

} 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.  

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.