Zsh Mailing List Archive
Messages sorted by:
Re: process substitution and Ctrl-C
- X-seq: zsh-users 15305
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxx
- Subject: Re: process substitution and Ctrl-C
- Date: Fri, 20 Aug 2010 08:24:18 -0700
- In-reply-to: <20100820115218.GC16241@xxxxxxxxxxxxxxxxxxx>
- List-help: <mailto:email@example.com>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <20100819124142.GQ16075@xxxxxxxxxxxxxxxxxxx> <20100819140730.70daeb3b@xxxxxxx> <20100819181556.4a3e6589@xxxxxxx> <20100819211853.33d720d8@pws-pc> <100819083237.ZM26692@xxxxxxxxxxxxxxxxxxxxxx> <20100819213717.5b5a7466@pws-pc> <20100819211721.GB16241@xxxxxxxxxxxxxxxxxxx> <100820011905.ZM28486@xxxxxxxxxxxxxxxxxxxxxx> <20100820115218.GC16241@xxxxxxxxxxxxxxxxxxx>
On Aug 20, 1:52pm, Vincent Lefevre wrote:
} Subject: Re: process substitution and Ctrl-C
} On 2010-08-20 01:19:05 -0700, Bart Schaefer wrote:
} > The process substitution can't really be synchronous in the sense of
} > sequential with respect to the rest of the job.
} I don't think this is specific to process substitution. This should
} also be the case for pipelines [...] But as far as I can see, a
} Ctrl-C interrupts all of them.
Yes, obviously. The difference is that a pipeline is organized as a
process group whose leader's PID is recorded in the job table, so even
historically, it was all managed together as one job. Conversely, a
process substitution (again historically) went into the background;
the closest pipeline analogy would be
prg1 | ( exec prg2 & )
Subsequent changes mean this behavior is no longer necessary, it was
merely preserved so that the new code behaved like the old code. I'm
not arguing that it should have been that way or should stay that way,
I'm just providing context.
} > On Aug 19, 11:17pm, Vincent Lefevre wrote:
} > } then the zsh prompt for the next command is displayed before "cat -n"
} > } finishes. Does this mean that process substitution should not be used
} > } for filtering, except when an end marker is used (as in the example
} > } at the end of my message)?
} > I'm not sure what question you're asking, [...]
} What I mean here is: the problem is that the main shell doesn't wait
} for "cat -n" to finish.
Yes, I get that; what I don't follow is what that has to do with using
process substitution for filtering and whether or not there's an "end
marker". Filtering implies that there's a downstream consumer of the
output of the filter, and using an end marker or not won't have any
effect on what's seen downstream. If you botch handling EOF from the
upstream in the middle of a pipeline, you'll get the same problem you
had with your process substitution (except that you'll be able to
interrupt the pipeline, even in older zsh).
The reason the manual explicitly calls out that process substitutions
are run asynchronously is to warn you about the ( prg2 & ) behavior.
We're discussing whether to change that and I think PWS's last patch
does so, but in the meantime if you don't want the backgrounding effect,
you're correct, you can't use a process substitution as if it were the
tail of a pipeline.
Messages sorted by: