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: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 79079 <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: bug#79079: 31.0.50; Piped command output is sometimes lost in Eshell
Date: Sun, 27 Jul 2025 12:14:24 -0700

On 2025-07-27 10:14, Eli Zaretskii wrote:
>> Date: Sun, 27 Jul 2025 09:15:09 -0700
>> Cc: jporterbugs <at> gmail.com, mail <at> daniel-mendler.de, 79079 <at> debbugs.gnu.org
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>> ...
>> Typically what a program will do in either situation is output an error
>> message and exit. Of course this exits just the program, not the shell
>> that invoked the program. Bash, for example, acts like this if bigstring
>> is long enough:
>>
>>     $ (trap "" PIPE; sleep 1; echo "$bigstring") |:
>>     bash: echo: write error: Broken pipe
>>     $
> 
> How ids all this working in the specific pipe command in question, and
> why does that piped command yield different results when run from a
> shell than when run from Eshell?

Sorry, I don't know.

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.

Previous Next

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