GNU bug report logs - #79079
31.0.50; Piped command output is sometimes lost in Eshell

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Wed, 23 Jul 2025 09:57:01 UTC

Severity: normal

Found in version 31.0.50

Full log


Message #29 received at 79079 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: mail <at> daniel-mendler.de, 79079 <at> debbugs.gnu.org
Subject: Re: bug#79079: 31.0.50; Piped command output is sometimes lost in
 Eshell
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.)




This bug report was last modified 32 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.