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

Previous Next

Full log

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 79079 <at> debbugs.gnu.org
Subject: Re: bug#79079: 31.0.50; Piped command output is sometimes lost in
 Eshell
Date: Mon, 28 Jul 2025 03:49:15 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

> 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.

Thanks, I am looking forward to that!

> 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.

Makes sense.

Daniel

Previous Next

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