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

From: Jim Porter <[email-masked]>
Date: Sun, 27 Jul 2025 22:35:07 -0700

On 7/27/2025 3:03 PM, Paul Eggert wrote:
> Thanks for the explanation. Is this documented? Might not hurt to do so 
> if it's not documented already. Maybe that can be part of your patch 
> series (and I can certainly sympathize with those patches taking time to 
> get right!)

Not anywhere explicitly. Since I'm finishing up some patches to let 
Eshell pipe to Lisp commands, it would probably be wise to explain some 
of the details of how piping is different in Eshell in the manual.

>>             ;; The output pipe broke, so send SIGPIPE to the
>>             ;; process.  NOTE: Due to the additional indirection
>>             ;; of Emacs process filters, the process will likely
>>             ;; see the SIGPIPE later than it would in a regular
>>             ;; shell, which could cause problems.
> 
> Suppose we change Emacs to not send SIGPIPE to A in this situation, but 
> instead to just close Emacs's end of A's output pipe. Then when A 
> eventually gets around to writing to its output pipe it will get a 
> SIGPIPE if it is not ignoring that signal, and an EPIPE failure 
> otherwise, and this will be closer to what happens with ordinary shell 
> pipes.

That's a good idea. I think that would be a much cleaner solution than 
what I wrote originally (which was somewhat limited since at the time I 
didn't have much familiarity with src/process.c). While it wouldn't be 
*exactly* the same as a POSIX shell, I think it would be close enough 
that it would be hard for a program to tell the difference.

Some sort of 'process-close-stream' function that lets the caller close 
the stdout or stderr stream for the process (or stdin, but I don't think 
I need that here) should do the trick. Even better if we can support 
that in Tramp.