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 #20 received at 79079 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>,
 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:34:03 +0300
> Date: Wed, 23 Jul 2025 11:06:24 -0700
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 7/23/2025 8:52 AM, Jim Porter wrote:
> > I'm not able to reproduce this locally, but if you first run 
> > "eshell-debug process", that will log a bunch of process-related 
> > information to the buffer "*eshell last cmd*". That would probably have 
> > some details that at least show where the I/O went missing.
> 
> After a few more tries, I was able to reproduce this very rarely. Does 
> the following patch help?
> 
> Eli: maybe you can help with some of the details here. 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).
> 
> Does that make sense?

Sounds a somewhat scary change, since this code was last touched 13
years ago.  Paul, WDYT?

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.




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.