Re: esh-proc test failures

[Jim Porter]

On 8/23/2022 9:22 AM, Eli Zaretskii wrote:
> > Cc: larsi@gnus.org, emacs-devel@gnu.org
> > From: Jim Porter <jporterbugs@gmail.com>
> > Date: Tue, 23 Aug 2022 08:57:37 -0700
> >
> > > I don't think I follow.  When the write fails, we get an error and
> > > propagate it all the way up to the caller.
> >
> > If we signal an error in a process filter, does Emacs inform the process
> > that wrote that data of the error? My tests showed that it didn't, but
> > maybe I was doing something wrong.
>
> Why are you talking about the process filter?  Does that filter call
> process-send-string to write to the next process in the pipe?  If so,
> it should inform Emacs about any errors in writing.

Yes. For the pipeline "foo | bar", the process filter for "foo" 
(eventually) calls 'process-send-string' for "bar". The code in Eshell 
is designed to do what you say.

The manual says, "If an error happens during execution of a filter 
function, it is caught automatically, so that it doesn’t stop the 
execution of whatever program was running when the filter function was 
started." As I understand it, since we *want* to stop execution, that 
means Eshell needs to be responsible for notifying "foo" if it failed to 
write to "bar". Eshell does that by signaling a special error 
('eshell-pipe-broken') when writing to "bar" after it terminated[1]; 
then, the process filter for "foo" can catch that and send a SIGPIPE 
signal[2] to "foo".

> > The goal here is just to tell a process that the thing it's writing to
> > is gone, and that it should give up.
>
> That cannot happen, because Eshell is in-between.  Instead, it is
> Emacs (Eshell) that should see the error, and deliver a signal to the
> relevant process if needed.

Then I think we're in agreement, since that's what Eshell currently 
does. (My sentence above was just trying to say that, *somehow*, Eshell 
needs to be sure that the relevant process is informed of the error. 
Delivering a signal is how Eshell does it now, and I think that's ok.)

[1] That's the behavior in my new patch. Previously, it signaled 
'eshell-pipe-broken' on any write error to "bar".

[2] Or some approximation of this on systems without SIGPIPE.