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

[Jim Porter]

On 2/19/2022 11:27 PM, Eli Zaretskii wrote:
> > Cc: 54062@debbugs.gnu.org
> > From: Jim Porter <jporterbugs@gmail.com>
> > Date: Sat, 19 Feb 2022 13:18:16 -0800
> >
> > > Many console programs catch SIGINT, though.
> > >
> > > Can't we terminate ("kill") the process instead?  Or maybe deleting
> > > the process object is enough?
> >
> > That might work; it would definitely be better than `interrupt-process'.
> > On the other hand, I think it would be nice to handle this case by
> > breaking the pipe if possible, since that would be closer to how it
> > works in regular shells, as I understand it.
>
> I meant killing the process as fallback for when SIGPIPE is not
> supported.

Ok, I've updated the patch to do this, with a note about how the 
behavior isn't quite correct. The current patch should work in most 
real-world cases, but if someone runs into a bug with this, hopefully 
the comment will point them in the right direction.

Note: I've only attached the updated patch here; parts 1-3 didn't 
change, so they're the same as in my original message[1].

> > Do you mean using `delete-process'? That works differently from how I'm
> > imagining things. From reading the code, `delete-process' sends SIGKILL
> > to the process group, but that means that a process that wants to do
> > something special in response to SIGPIPE (or EPIPE, or ERROR_BROKEN_PIPE
> > on Win32) wouldn't be able to, since that's not the signal/error it
> > receives.
>
> How else can you close the pipe without deleting the process?  How can
> Emacs have a process whose I/O channels aren't ready to be used?
>
> I thought you were talking about a pipe process (make-pipe-process),
> in which case deleting it closes the pipe.  But you seem to mean
> something else, so now I'm not sure I understand.

By "pipe", I meant the pair of file descriptors created by the pipe 
function (technically, `emacs_pipe') inside `create_process'. In this 
case, the subprocess being created will get the write end of that pipe, 
while Emacs gets the read end. If Emacs closes the read end of the pipe, 
then the next time the subprocess tries to write to its end of the pipe, 
it will get an error (SIGPIPE, EPIPE, or ERROR_BROKEN_PIPE, depending on 
the situation).

That's the behavior that the subprocess would expect: if the pipe for 
its stdout fd is broken, the error should refer to that problem (e.g. 
via signalling SIGPIPE). Raising the error in a different way (e.g. via 
SIGKILL) isn't quite correct.

However, as you correctly state, this is a niche feature, and messing 
around with Emacs's process management shouldn't be done lightly. It 
would take a lot of testing to be sure my previous patch is right, 
especially since my understanding of Emacs's process.c is pretty 
rudimentary. As you suggested, I think this new implementation should be 
a reasonable fallback.

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-02/msg01431.html

0004-Send-SIGPIPE-to-external-Eshell-processes-if-their-o.patch
Description: Text document