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

Re: Re: exit value of intermediate program in pipe



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



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