At Wed, 23 Sep 2026 11:25:52 -0700, "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon%orthanc.ca@localhost> wrote: Subject: Re: SIGPIPE-equivalent before writing? > > Johnny Billquist writes: > > find / -name foobar | tee check.log | more > > > > And then after a while I get bored and quit more. Should the tee be > > killed then, and in turn the find? (in this particular example unless the find is hung waiting on a very slow or unresponding NFS mount or device or similar it will produce output and the tee will then also produce output and boom, they both get a SIGPIPE) > Since all these cases seem to be interactive, maybe it would be > better to handle this in the shell. Add a shell option that > kills the entire pipeline when the last process in the pipeline > dies. I think that's actually a rather un-Unix-like solution. :-) Also, how do you change the option if you've already got the pipeline running (especially if there's a bug that doesn't let you change it for a job that's been stopped, assuming the shell has job control, or if the shell doesn't have job control)? Also, what if it's not the last process that exits early, but one in the middle? As I asked earlier, if it's merely a minor annoyance for interactive users, then why not just accept that there's already an easy interactive way to deal with it? Taylor originally asked: > > How can or should applications do this right, so that the producer can > subscribe to a notification of when the consumer of a pipeline has > (exited and) closed the reading side of the pipe, instead of only > getting a notification when the producer next tries to write output? I think that's also a very un-Unix-like approach to the problem, thus my original questions and suggestions. Edgar pointed out that the pager can't know if you want the feeder to finish or not, which is quite true (and is true for other things in or at the end of pipelines that might exit before their feeders). That's why I pointed out that the user can always decide what should happen by either generating a SIGINT from the TTY, or, by implication, of course one could just wait, or one could put the job into the background (assuming a modern shell with job control). Of course there could also be a special way to quit the pager such that it would kill the pipeline first, and the user could choose that method, but it seems like a rather clumsy and error-prone solution whereas there's already a perfectly good set of ways for the user to deal with the situation after quitting the pager the normal way. I.e. I think the Unix choice of waiting for the next write(2) to generate a SIGPIPE, or for the user to generate SIGINT (or SIGSTOP), is correct and is an ideal compromise, and the myriad of different issues with trying to do something else automatically by implementing new code in either all the possible things that might feed pipelines to pagers, or new code in the pager, when there's already a suitable way for the user to decide what to do, is very un-Unix-like. The only caveat might be that it can be confusing to new users as to why their prompt doesn't always immediately appear when they quit the pager, but in my experience it doesn't take very long for them to learn to send SIGINT from the TTY. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpaddPtkkNs9.pgp
Description: OpenPGP Digital Signature