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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 26 Jul 2025 13:15:21 +0300

> Date: Thu, 24 Jul 2025 08:52:16 -0700
> Cc: [email-masked], [email-masked]
> From: Jim Porter <[email-masked]>
> 
> 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.

So calling the filter of the "head"s process when we get EPIPE should
fix that, no?