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 09:15:09 -0700

On 2025-07-27 08:38, Eli Zaretskii wrote:
>> Date: Sun, 27 Jul 2025 08:06:10 -0700
>> Cc: mail <at> daniel-mendler.de, 79079 <at> debbugs.gnu.org
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>>
>> Not sure I know what you mean by "doing what a Posix shell does". Are
>> you talking about commands that a shell implements directly, like the
>> shell 'echo' command typically is? If so, those commands are supposed to
>> do what their standalone counterpart executables do, which typically
>> means they die due to getting a SIGPIPE signal.
> 
> I meant wrt data still buffered in the broken pipe(s) and standard
> streams.

Still not quite sure I follow what's being asked, but here goes.

There's no way for any program writing to a pipe to know what's in the 
kernel's buffers for the pipe, so there's nothing to do there.

For buffers in user space (e.g., stdout's buffer), once a program has 
gotten EPIPE there's no point to any further writes or fflushes; the 
program will just get more EPIPEs.

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
  $

Previous Next

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