🚀 go-pugleaf

On Tue, 14 Jul 1998 22:44:29 GMT, Wayne Throop <throopw@sheol.org> wrote:
>:: I you are going to do a
>::          ps -ef | grep 'something'
>:: and you don't wanna see  the   grep 'something',
>:: but only the true result - what are you going to write
>:: to left out the 'grep' line ??????
>
>: Christian Tremblay <chris@terax.com>
>: ps -ef | grep 'something' | grep -v grep

ps -ef | grep '[s]omething'


>Or, since what you do is ensure the ps process doesn't include
>the grep process in the ultimate output, ensure the grep isn't
>running when the ps runs.  I have a pipe fitting for that,
>
>          ps -ef | pseq | grep something
>
>              (where "pseq" acts like (cat >tmp; cat tmp; rm tmp))

It's still a race condition that you might pick up the grep,
though the timing is more favorable to it being missed.


>Note, I made myself a pseq when I had a case where a writer blew up
>ungracefully if ever a reader of its stdout didn't read all the way
>to the end (that is, behaved ungracefully upon receipt of a SIGPIPE).
>Thus, the pipe fitting to make an panic-prone writer cooperate
>with a lazy reader; also useful in this case.

Wouldn't it be better to implement pseq like
   (cat; exec cat >/dev/null)
?  (I.e., copy stdin to stdout; when the first cat dies (due to
SIGPIPE or EOF, copy the remainer of stdin to /dev/null.)
(Better still if this is implemented in C or perl so that the
second ``cat'' equivalent does not get run if the first one quits
due to EOF; it won't make a difference in a pipeline, but it'd
be much better should pseq ever is used with a tty on stdin.)
This avoids the creation of a potentially huge temp file,
and allows the process(es) to the right of the pseq to run in
parallel with the process(es) to the left, while still isolating
the process(es) on the left from SIGPIPE misbehavior.

		--Ken Pizzini