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

From: Jim Porter <[email-masked]>
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.