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


View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 79079 <at> debbugs.gnu.org
Subject: bug#79079: 31.0.50; Piped command output is sometimes lost in Eshell
Date: Sun, 27 Jul 2025 13:08:52 -0700
On 7/27/2025 12:53 PM, Daniel Mendler via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Only tangentially related to this bug report, but I wonder if it would
> make sense to always use actual pipes in Eshell when possible, instead
> of the process filter indirection?
> 
> There exists already the *| operator from `em-extpipe'. What prevents us
> from making it the default (or enable it via customization) if `sh' is
> available? The downside is that `sh' is started as an intermediate
> process, but are their other downsides? For example piping though an
> Elisp function, which transforms the input, would not work, but this is
> not yet supported, or is it? As far as I understand *| is often more
> efficient, despite starting a separate shell process.

Eshell will support piping to Lisp commands Soon(TM). I'm finishing up a 
patch series that I hope to upload for discussion shortly. This has 
taken a *long* time to get to the point where I haven't run into any 
major issues, but it's finally coming together.

The larger problem is that it's impossible to determine at 
command-parsing time whether a particular command is implemented 
entirely in Lisp or will create a child process. "cat" is a good 
example: even as the leftmost command in a pipeline, sometimes it's a 
Lisp command, and other times, it creates a child process by throwing 
'eshell-external' to replace the Lisp version of the command. That makes 
it challenging to connect the pipes up correctly, since we don't know 
which commands have real OS-provided pipes until command execution. I'm 
not saying it's impossible, but it's definitely not easy.




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.