From: Vincent Lefevre <vincent@vinc17.net>
To: zsh-users@zsh.org
Subject: Re: process substitution and Ctrl-C
Date: Fri, 20 Aug 2010 13:52:18 +0200 [thread overview]
Message-ID: <20100820115218.GC16241@prunille.vinc17.org> (raw)
In-Reply-To: <100820011905.ZM28486@torch.brasslantern.com>
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. The intention is to
> run in parallel so that multios can send data to many processes at
> once. I think the rest of the behavior was ill-defined side-effect.
I don't think this is specific to process substitution. This should
also be the case for pipelines, such as:
prg1 | prg2 | prg3 | prg4
All of the should be run in parallel to avoid a possible deadlock
due to buffering (and this should also be faster on today's desktop
machines, which have several cores). But as far as I can see, a
Ctrl-C interrupts all of them.
> On Aug 19, 11:17pm, Vincent Lefevre wrote:
> } However there's a race condition, IMHO. In fact, even without a signal
> } to the main process. For instance, if you consider:
> }
> } ls >>(cat -n)
> }
> } 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. This means that on a typical machine, the zsh
prompt will here be displayed before the "cat -n" output. This should
be more clear with:
ls >>(sleep 2; cat -n)
I would like the same behavior as:
{ ls } >>(sleep 2; cat -n)
> } For instance:
> }
> } { ls } >>(while read line; do sleep 1; echo $line; done)
> }
> } outputs one line each second, and the main process is blocked as
> } wanted; but if one does a Ctrl-C, the main process is terminated
> } and one gets the prompt while the substituted process still outputs
> } the remaining lines each second. I don't think this is the behavior
> } that one expects.
>
> As noted above, that's the only behavior that could be accomodated in
> the original code base ... so it _is_ what someone who has been using
> zsh since 1993-ish would expect. :-)
I think the average user would expect process substitution to behave
a bit like pipes w.r.t. signals, e.g. like:
ls | while read line; do sleep 1; echo $line; done
The fact that the right part is in the foreground doesn't matter.
One can see that everything is killed with a more complex one:
{ echo foo; sleep 5; echo bar } | \
{ while read line; do sleep 1; echo $line; done; echo blah >&2 } | \
{ sleep 10; read a; echo $a; sleep 2; cat }
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
next prev parent reply other threads:[~2010-08-20 11:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-19 12:41 Vincent Lefevre
2010-08-19 13:07 ` Peter Stephenson
2010-08-19 17:15 ` Peter Stephenson
2010-08-19 20:18 ` Peter Stephenson
2010-08-19 15:32 ` Bart Schaefer
2010-08-19 20:37 ` Peter Stephenson
2010-08-19 21:17 ` Vincent Lefevre
2010-08-20 8:19 ` Bart Schaefer
2010-08-20 11:52 ` Vincent Lefevre [this message]
2010-08-20 15:24 ` Bart Schaefer
2010-08-21 0:04 ` Vincent Lefevre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100820115218.GC16241@prunille.vinc17.org \
--to=vincent@vinc17.net \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).