Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

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.  So the grep
> > won't get EOF when blah exits.  You have to shut it down some other way;
> > the only thing I've found is to start another coprocess.  I don't know
> > if this is a bug, or what.
>         at first, i wasn't sure if this would be a bug or not; it would
> make some conceptual sense to have a "coprocess exit" command that closed
> out a coprocess, and when i tried to find some docs on coproc, all i could
> find was the fmli coproc, which uses a similar cocreate/codestroy metaphor.
> as far as i can tell, though, zsh coproc just swallows the eof, since doing
> an
> echo "^D" >&p
> should otherwise have the same effect as "coproc exit", but doesn't.  and
> _that_ is something that i _would_ consider a bug.

In ksh, the normal way to kill a coproc is

  exec 3<&p 3<-

because just killing the job doesn't close the file descriptor. In
zsh-3.1.3, this doesn't work (a bug, IMHO), but you can kill the job
without getting problems.


>         does this mean that you can only have one coproc open at a
> time?  i could see situations where it might be useful to have more
> than one coproc open at once, rather than opening and closing the
> same two executables over and over in rapid succession.

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

Now you can communicate with f and g separately:

  print -u3 "to f"
  read -u4 x     # from f
  print -p "to g"
  read -p y      # from g

Regards,
	Bernd
--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@xxxxxxxxxxxxxxxxxx
http://www.rrz.uni-hamburg.de/eggink/BEggink.html



Messages sorted by: Reverse Date, Date, Thread, Author