Re: esh-proc test failures

[Eli Zaretskii]

> Cc: larsi@gnus.org, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Mon, 22 Aug 2022 20:53:47 -0700
> 
> >> The only thing that really needs to happen here is that the signal is
> >> caught so it doesn't bubble up past this point and break things.
> > 
> > How do you accomplish that?  On MS-Windows there's no SIGPIPE signal,
> > for example.
> 
> If Eshell tries to write to a process object and it fails, it gets 
> treated as a broken pipe. Technically, it signals 'eshell-pipe-broken', 
> but that's roughly equivalent to SIGPIPE. This is mainly so that in a 
> pipeline like "foo | bar", if "bar" terminates, Eshell can inform "foo" 
> of the fact; on POSIX systems, it would send SIGPIPE, but on MS Windows, 
> it just calls 'delete-process'. This is important because we want to be 
> sure that if you have a pipeline like "yes | head", the "yes" gets 
> stopped once "head" is done.

So you basically assume that _any_ problem in the pipe was due to
SIGPIPE?  That could be too optimistic: it could be due to something
much more mundane and unrelated.

> > Not sure I understand completely what you are saying here, but AFAIR
> > writing to a closed pipe on MS-Windows will cause EINVAL errno.
> 
> Indeed, it would be nice if we could force things so that an MS Windows 
> program gets EINVAL for its WriteFile call, but because Eshell only 
> interacts indirectly with the program's output, it's too late to do that 
> by the time Eshell responds.

I don't think I follow.  When the write fails, we get an error and
propagate it all the way up to the caller.

> >> I could expand the comment to explain that this value is
> >> somewhat-arbitrary and just designed to match GNU/Linux.
> > 
> > Yes, please.
> 
> How does the attached look?

Looks OK, but are you sure about the "128" part? shouldn't it be 256
instead?  And perhaps explain why you add 128 (or whatever).

> Well, it depends on what we think users would expect. Currently, I don't 
> think Eshell provides the necessary functionality to tell when the 
> process "foo" fails (i.e. returns a non-zero exit status) in the 
> pipeline "foo | bar".

But we can do that, right?  The information about the exit status is
available to the SIGCHLD handler or a similar interface.