zsh-users
 help / color / mirror / code / Atom feed
From: Sweth Chandramouli <sweth@astaroth.nit.gwu.edu>
To: zsh-users@math.gatech.edu
Subject: Re: Re: exit value of intermediate program in pipe
Date: Mon, 4 May 1998 00:54:04 -0400	[thread overview]
Message-ID: <19980504005404.54023@astaroth.nit.gwu.edu> (raw)
In-Reply-To: <980503183549.ZM1342@candle.brasslantern.com>

On Sun, May 03, 1998 at 06:35:49PM -0700, Bart Schaefer wrote:
[snip]
> That line doesn't do what you think.  What you'd want is just
[snip]
> That's not right either.  You'd probably need
[snip]
	that's what i was talking about with the need for more examples;
the FAQ did have the fact that |& uses the csh syntax, which i had missed,
but has no reference that i could find to >&p or how to use it, and i 
think that my (wrong) interpretation was reasonable based on the description
in the manpage.

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

> So you get
> 
>     {
> 	coproc grep -v bar
> 	cat <&p &
> 	/bin/blah >&p
> 	exitstatus=$?
> 	coproc exit	# Shuts down grep by closing its input, as
> 			#   a side-effect of starting a new coproc
> 			#   which then immediately exits.  Ewww.
	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.

> 	wait		# Allows cat to finish, just in case.
> 	return $exitstatus
>     }
> 
> I think { /bin/blah >>(grep -v bar) } is a lot nicer, don't you?

	true, but it still ends when the first process ends, which
could cause problems if the other process were something other than
a grep, right?  making grep a bg-ed process (or coproc) was
the point of all this, after all, so that wait would recognize it.
	the next question would be, how efficient is the coproc? 
is it still worth it to go through all of these hoops rather than
just write the output to a temp file?  i would imagine so.   

	-- sweth.

-- 
"Countin' on a remedy I've counted on before
Goin' with a cure that's never failed me
What you call the disease
I call the remedy"  -- The Mighty Mighty Bosstones


  reply	other threads:[~1998-05-04  4:59 UTC|newest]

Thread overview: 24+ 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 [this message]
1998-05-04  9:43             ` Bernd Eggink
1998-05-04 11:42               ` Bart Schaefer
1998-05-04 12:03                 ` Bernd Eggink
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

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=19980504005404.54023@astaroth.nit.gwu.edu \
    --to=sweth@astaroth.nit.gwu.edu \
    --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).