On 7/24/2025 6:52 AM, Paul Eggert wrote:
> On 2025-07-23 22:34, Eli Zaretskii wrote:
>>> Date: Wed, 23 Jul 2025 11:06:24 -0700
>>> From: Jim Porter<jporterbugs@gmail.com>
> 
>>> In process.c,
>>> when we write to a process, we handle EPIPE errors by calling
>>> 'deactivate_process'. However, that can lead to us dropping any data
>>> written*by* that process, since we don't call the process's filter
>>> function for any remaining output still in our internal buffer.
>>>
>>> I think in this case, we'd just want to let the rest of our code handle
>>> deactivating the process in the usual way. That helps fix this bug, plus
>>> I think it makes sense in general. If a process closes stdin, I believe
>>> we'd get the EPIPE error, but that process might want to continue
>>> working (though it does mean that you could only interact with that
>>> process via signaling it).
> 
> Yes, that makes sense.

Thanks for checking. Then I think the attached diff would be close to 
what we want, with a few caveats. (The original diff was just the 
smallest change that seemed to fix the problem so that Daniel could try 
it out.)

This diff changes things so that when we get an EPIPE, we close our end 
of the pipe (the 'WRITE_TO_SUBPROCESS' fd). I don't know if we need to 
do anything special for PTYs or sockets though.

On the Eshell side then, we previously detected EPIPE by checking 
whether the process had been deactivated. Since that doesn't happen 
anymore, I changed it so that we always treat an error from 
'process-send-string' as though the pipe broke. In practice, this just 
means that Eshell will think that all future calls to 
'process-send-string' would fail too (and so it will send a SIGPIPE 
signal to the sending process; "git" in the original test case). I'm not 
totally sure that's right though. Could there be a time when we get an 
error from 'process-send-string', but we can try calling it again later?