GNU bug report logs -
#79079
31.0.50; Piped command output is sometimes lost in Eshell
Previous Next
Full log
View this message in rfc822 format
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.