Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> > ... if SIGPIPE is blocked or ignored. >> > >> >> which is not generally recommended. >> >> In some contexts. Some environments (mis-configured login/csh) have >> resulted in the default SIGPIPE handler being SIG_IGN. > > I agree that having SIGPIPE blocked or ignoring during an execve() or > posix_spawn() call is a bad idea. The best strategy for a program that > wants to write to a subprocess is therefore to > 0. ensure the SIGPIPE handler is set to SIG_DFL. > 1. spawn the subprocess, > 2. switch the SIGPIPE handler to SIG_IGN, > 3. start writing to the subprocess. > >> > If you want both scenarios - the "don't know which of the two terminates >> > first" >> > and the "writer must terminate first" - to be supported by close_stream and >> > close_stdout, IMO the program needs to be able to tell these functions >> > about >> > it, probably through a global variable 'bool ignore_epipe' or similar. >> >> Using a global variable would not be appropriate for library code like >> this. What if two applications using the same library want to use >> different policies? > > You can distinguish close_stream and close_stdout. close_stream is library > code, > close_stdout is not. What about a 'bool ignore_epipe' that influences the > behaviour of close_stdout? Whereas the library code that called close_stream > has to check against EOF/EPIPE itself if it wants to.
Indeed. This sounds workable, perhaps using a new close_stdout_ignore_epipe function. > That would satisfy the "don't know which of the two terminates first" scenario > (the 'msgfilter' case), and your scenario of "writer must terminate first" > as well. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
