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

[Eli Zaretskii]

> 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.

> >> 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?
> 
> 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.

> In my patch, `process-break-pipe' just closes the file descriptor for 
> the read end of the process's stdout pipe, but otherwise doesn't do 
> anything to the process.

I don't think this is a good idea.  A process isn't supposed to be in
this state.

> Then, when the process tries to write to stdout 
> again, the OS will report (via a signal and/or an error code) that the 
> pipe is broken. Since Win32's WriteFile[1] API returns ERROR_BROKEN_PIPE 
> in this case, that would let MS Windows programs detect and respond to 
> broken pipes in the usual way for that platform.

We don't use WriteFile directly, and I wouldn't rely on EPIPE being in
errno in this case without extensive testing.

Anyway, the proposal to close the pipe of a live process object is
problematic, see above.  I hope we can come up with something
simpler.  We are talking about a niche feature here, so it is IMO
better to find a simple solution for that.