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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: jporterbugs <at> gmail.com, 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 17:56:35 +0300

> Date: Thu, 24 Jul 2025 06:52:39 -0700
> Cc: mail <at> daniel-mendler.de, 79079 <at> debbugs.gnu.org,
>  Jim Porter <jporterbugs <at> gmail.com>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> >> 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.
> 
> 
> > What about calling the filter with the data we still have?  Isn't that
> > what a Posix shell would do -- flush any buffers?
> 
> Not sure what you man by that, but I suspect it wouldn't handle the 
> scenario Jim describes, where the other process closes its end of the 
> pipe but keeps running. Emacs shouldn't assume that EPIPE means the 
> other process has died or has closed any pipes other than the one Emacs 
> got EPIPE on.

I guess I'm confused: if the other process closed its end of the pipe,
why do we care about the stuff we have in our buffers that wasn't yet
piped to that other process?

Previous Next

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