zsh-users
 help / color / mirror / code / Atom feed
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


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