bug#54062: 29.0.50; [PATCH] Eshell should inform processes when a pipe is broken

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 54062@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Sat, 19 Feb 2022 12:02:45 -0800
> 
> > SIGPIPE isn't supported on MS-Windows, so I think we should have a
> > fallback there for platforms that don't support SIGPIPE.
> 
> Hmm, good point. Thinking about this some more, this also won't work for 
> Tramp (which only supports `interrupt-process' as far as I can tell). I 
> can think of a couple possible solutions.
> 
> One option would be to call `interrupt-process' instead, since that 
> works in all cases I'm aware of. This isn't quite as nice as sending 
> SIGPIPE (or equivalent) to let the process handle it how it wants, but 
> at least `interrupt-process' has the same default behavior as SIGPIPE 
> (i.e. terminate the process).

Many console programs catch SIGINT, though.

Can't we terminate ("kill") the process instead?  Or maybe deleting
the process object is enough?

> Another way would be to add a function like `process-break-pipe' (it 
> could probably use a better name) that would close the read end of the 
> process's output pipe, which - if I understand the Win32 API here - 
> should trigger the right behavior on MS Windows too.

You mean, delete the process object?  That's how we close our end of
the pipe, no?

> One caveat is that the head process (`yes' in the example), would only 
> see the "broken pipe" error on the *next* write after the one where 
> Eshell detected the broken pipe. That's easy enough to fix for cases 
> where we can signal SIGPIPE directly, but it's probably ok in general 
> too: after all, processes don't generally know exactly when a SIGPIPE 
> might occur, so it occurring slightly later shouldn't cause problems. 

I don't see a problem here.  AFAIU, closing a pipe doesn't always
deliver SIGPIPE, it can instead fail the write with EPIPE.  So SIGPIPE
is not guaranteed anyway.

> (In theory, the tail process should call `process-break-pipe' as soon as 
> it closes, but in Eshell, the tail process doesn't know what's feeding 
> it input, so it can't easily do this.)

Not sure I understand: an Emacs process object always knows what's
feeding it.