From: Bernd Eggink <eggink@uni-hamburg.de>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-users@math.gatech.edu
Subject: Re: exit value of intermediate program in pipe
Date: Mon, 04 May 1998 14:03:07 +0200 [thread overview]
Message-ID: <354DAE7B.F65FE723@rrz.uni-hamburg.de> (raw)
In-Reply-To: <980504044259.ZM3556@candle.brasslantern.com>
Bart Schaefer wrote:
> On May 4, 11:43am, Bernd Eggink wrote:
> } Subject: Re: exit value of intermediate program in pipe
> }
> } Sweth Chandramouli wrote:
> } > > The last problem is that grep won't exit until it sees EOF on its stdin,
> } > > but >&p dups the coproc input without actually closing it.
> }
> } In ksh, the normal way to kill a coproc is
> }
> } exec 3<&p 3<-
>
> Do you mean 3<&- or is <- magic in ksh? (In zsh, <&- is magic but it only
> works on stdin, it doesn't take a digit to the left.)
>
> } because just killing the job doesn't close the file descriptor.
>
> It may not in zsh either. Anyway, I'm curious about that ksh-ism, because
> it closes the coproc's *output*, not it's input
Huh? Of course it closes it's input; that's what < means!
> -- so it's assuming that
> the coproc will die on a "broken pipe" signal, which isn't necessarily
> true. (As my "yes" example demonstrates, closing the input won't always
> work either, but presumably you don't normally coproc something that is
> going to ignore its input.)
>
> My "coproc exit" hack works because it closes the old coproc input so as
> to not leak the descriptor. But it wouldn't have been incorrect for it
> to leave it open, as far as documented behavior goes (which isn't far).
>
> } In
> } zsh-3.1.3, this doesn't work (a bug, IMHO), but you can kill the job
> } without getting problems.
>
> If you kill the job, you may lose some of its output. The only correct
> way is to close the input and let it die in its own good time.
That's what I said - but it doesn't work.
> Can somebody out there who has ksh tell me whether
>
> cat |&
> echo >&p
>
> causes cat to exit? That is, does redirection to the coproc make the
> coproc input no longer available to any other process?
Yes, it does.
[...]
>
> That is, zsh will re-open the same coproc input as often as you like,
> and never closes it until you start a new coproc. Does ksh do that?
No.
> } You can have more than one coprocs at a time. Just copy the fd's:
> }
> } coproc f
> } exec 3>&p 4<&p # or whatever numbers you like
> } coproc g
>
> Right; if you do that, then my "coproc exit" trick won't stop the first
> coproc, because its input has already been dup'd once and the dup is
> kept open.
So in this case 'kill' seems to be the only way to get rid of the first
n-1 coprocs...
--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@rrz.uni-hamburg.de
http://www.rrz.uni-hamburg.de/eggink/BEggink.html
next prev parent reply other threads:[~1998-05-04 12:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-05-02 22:24 Steve Talley
1998-05-03 0:50 ` Sweth Chandramouli
1998-05-03 1:38 ` Timothy J Luoma
1998-05-03 2:08 ` Bart Schaefer
1998-05-03 6:17 ` Sweth Chandramouli
1998-05-03 9:30 ` Bart Schaefer
1998-05-03 22:15 ` Sweth Chandramouli
1998-05-04 1:35 ` Bart Schaefer
1998-05-04 4:54 ` Sweth Chandramouli
1998-05-04 9:43 ` Bernd Eggink
1998-05-04 11:42 ` Bart Schaefer
1998-05-04 12:03 ` Bernd Eggink [this message]
1998-05-04 15:59 ` Bart Schaefer
1998-05-05 11:39 ` Bernd Eggink
1998-05-05 17:03 ` zsh vs. ksh coproc redirection semantics Bart Schaefer
1998-05-06 10:47 ` Bernd Eggink
1998-05-06 16:00 ` Bart Schaefer
1998-05-07 7:17 ` Zoltan Hidvegi
1998-05-07 8:34 ` Andrew Main
1998-05-07 9:26 ` Bart Schaefer
1998-05-07 9:34 ` Andrew Main
1998-05-07 17:02 ` Zoltan Hidvegi
1998-05-07 9:18 ` Bart Schaefer
1998-05-07 17:10 ` Zoltan Hidvegi
1998-05-05 11:54 exit value of intermediate program in pipe Bernd Eggink
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=354DAE7B.F65FE723@rrz.uni-hamburg.de \
--to=eggink@uni-hamburg.de \
--cc=schaefer@brasslantern.com \
--cc=zsh-users@math.gatech.edu \
/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).