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

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: bug#79079: 31.0.50; Piped command output is sometimes lost in Eshell
Date: Sun, 27 Jul 2025 21:53:33 +0200

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

> On 7/27/2025 12:14 PM, Paul Eggert wrote:
>> From Jim's recent email it sounds like Eshell does not actually set up a pipe
>> when implementing "A | B", but instead does something else that simulates a
>> pipe. I don't know how the simulation works, but it sounds like the simulated
>> pipe cannot act like a real pipe when B closes its end of the simulated pipe,
>> A ignores SIGPIPE, and A writes to the simulated pipe. With a real pipe A
>> would get an EPIPE error, and I guess that's not happening with the simulated
>> pipe.
>
> If we're being technical, Eshell does use pipes for its pipe operator, but
> there's an additional layer of indirection that makes it difficult to simulate
> the usual POSIX shell piping:
>
>   process A -> stdout pipe -> process filter -> process-send-string -> stdin
>  pipe -> process B

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.

Exposing Unix pipes to directly glue file handles on the Elisp level
would be another option, but it is probably difficult to integrate this
into the existing process API?

Daniel

Previous Next

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