Re: exit value of intermediate program in pipe

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On May 4, 12:54am, Sweth Chandramouli wrote:
} Subject: Re: Re: exit value of intermediate program in pipe
}
} 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.

I've already bugged zsh-workers about the manpage deficiency.

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

No, that's not a bug; ctrl-D only means EOF on tty devices; sending one
down any other kind of stream is just sending a byte with the value \004.
This isn't DOS where a magic character in any text stream is read as EOF.

} > I think { /bin/blah >>(grep -v bar) } is a lot nicer, don't you?
} 
} 	true, but it still ends when the first process ends

No, not quite; it gets EOF when the first process ends, but if it doesn't
happen to be a program that exits when it gets EOF on stdin, it'll just
keep running.

	echo goodbye >>(yes hello)

produces an unstoppable and rather difficult to kill stream of hellos on
your terminal.  On some OSs even exiting the tty session many not get rid
of it (linux 2.0.x being one of them).

} making grep a bg-ed process (or coproc) was
} the point of all this, after all, so that wait would recognize it.

That ought to be fixed by putting process substitutions in the job table.

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

Probably depends on just how much output we're talking about.  The coproc
is a pipe, so it doesn't have any filesize limit or quota on its input and
output.

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

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?  In zsh, I can do

	coproc cat
	while true; do echo foo >&p; done &
	while true; do echo bar >&p; done &
	cat <&p

and get back

	foo
	foo
	foo
	bar
	foo
	bar
	foo
	bar
	bar
	foo

	(etc. until killed)

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?

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

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com