Subject: bug#79079: 31.0.50; Piped command output is sometimes lost in Eshell

From: Eli Zaretskii <[email-masked]>
Date: Sun, 27 Jul 2025 20:14:01 +0300

> Date: Sun, 27 Jul 2025 09:15:09 -0700
> Cc: [email-masked], [email-masked], [email-masked]
> From: Paul Eggert <[email-masked]>
> 
> On 2025-07-27 08:38, Eli Zaretskii wrote:
> >> Date: Sun, 27 Jul 2025 08:06:10 -0700
> >> Cc: [email-masked], [email-masked]
> >> From: Paul Eggert <[email-masked]>
> >>
> >> 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
>    $

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?

That's basically what I'm asking.  And as a corollary, what should we
do so that the result in Eshell will be the same as from a shell, and
why?