Subject: bug#79079: 31.0.50; Piped command output is sometimes lost in Eshell

From: Jim Porter <[email-masked]>
Date: Thu, 24 Jul 2025 08:52:16 -0700

On 7/23/2025 10:34 PM, Eli Zaretskii wrote:
> What about calling the filter with the data we still have?  Isn't that
> what a Posix shell would do -- flush any buffers?
> 
> And why do we get EPIPE in the recipe in this bug, anyway?  I'd like
> to understand better at least one situation where we get EPIPE while
> the data received before that still matters.

In the recipe, we pipe "git log" to "head -n 10", where Eshell handles 
the actual piping. (I don't think Eshell's presence here is actually 
necessary to see this bug, though it's probably the simplest way to 
reproduce it in Emacs.)

"git log" produces a bunch of output that gets sent to Eshell's process 
filter. That filter eventually calls 'process-send-string' on the "head" 
process, forwarding all of git's stdout to head's stdin. Immediately 
after that, head sees that it's already gotten 10 lines of input, so it 
exits. "git log" doesn't know that yet, so it sends another batch of 
text to Eshell's process filter, which again gets passed to 
'process-send-string'. This time around though, the pipe to head's stdin 
has been closed, so we get an EPIPE. Currently, Emacs deactivates the 
head process, but because of how the timings worked out, all this 
happens *before* Eshell's process filter for head ever runs. As a 
result, Emacs never see the output that head produced.

Thinking about this more, my previous comment that the output from the 
head process is in an internal buffer in Emacs probably isn't accurate. 
That *could* happen, but in some cases, we may not have called 'read' 
yet, so the data could still be in the OS's buffer. (I'd have to write 
some test cases to be 100% sure of all this, but it follows from the 
manpages.)