Re: parse error in process substitution

["Mikael Magnusson" <mikachu@xxxxxxxxx>]

2008/11/13 Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>:
> On Mon, 10 Nov 2008 09:21:52 +0100
> Louis-David Mitterrand <vindex+lists-zsh-users@xxxxxxxxxxx> wrote:
>> So how would you convert that working bash command to zsh?
>>
>>       root-tail <(ssh root@xxxxxxxxxxxx tail -F /var/log/kern.log),red,
>
> This fixes the syntax.  Unfortunately, I had to impose some limitations
> to prevent existing stuff stopping working.  Obviously I'd like to
> know about anything else this messes up.  I'm not worried about
> the undocumented feature that <(...) forced a new word.
>
> 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.  However, you can now put other things after
> it.
>
> ">" 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.  (The comptest function falls over if
> this isn't done.)  This isn't likely to be a big problem
> in practice.  Because of the previous rule this isn't relevant to
> =(...).
>
> 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).
>
> Index: README
> ===================================================================
> RCS file: /cvsroot/zsh/zsh/README,v
> retrieving revision 1.58
> diff -u -r1.58 README
> --- README      30 Oct 2008 12:18:54 -0000      1.58
> +++ README      13 Nov 2008 20:46:40 -0000
> @@ -69,6 +69,16 @@
>  consistent with recent versions of other shells.  The option
>  DEBUG_BEFORE_CMD can be unset to revert to the previous behaviour.
>
> +Previously, process substitutions of the form =(...), <(...) and
> +>(...) were only handled if they appeared as separate command arguments,
> +although the latter two forms caused a new command argument to be
> +started at that point.

This sentence is somewhat confusing, but i guess it means that <() and
>() always started a new command argument even if they weren't
separate... :)

> +Now all three may be followed by other strings,
> +and the latter two may also be preceeded by other string.

strings

> +is subject to process substitution.  The expression may be proceeded

preceeded

> +or followed by other strings except that, to prevent clashes with
> +commonly occurring strings and patterns, the last
> +form must occur at the start of a command argument, and none of
> +the forms may occur inside parentheses used for grouping of patterns or
> +inside parameter substitutions.
> +
>  In the case of the tt(<) or tt(>) forms, the shell runs process
>  var(list) asynchronously.  If the system supports the tt(/dev/fd)
>  mechanism, the command argument is the name of the device file

Should this be "the process list"?

-- 
Mikael Magnusson