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 12:23:37 -0700
> 
> >> +    (eshell-pipe-broken
> >> +     ;; 141 is 128 + 13 (the numeric value of SIGPIPE).
> >> +     (setq eshell-last-command-status 141)
> >> +     nil)
> > 
> > This is non-portable, I think on two counts:
> > 
> >   . the assumption that the exit code is the signal number left-shifted
> >     by N bits (btw, isn't N = 8, not 7?)
> >   . the assumption that SIGPIPE is signal 13 (does Posix mandate that?)
> > 
> > What do we expect to happen here on MS-Windows and other non-Posix
> > platforms, where both of the above assumptions are false?
> 
> 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.

> The 
> command status could be anything really, and I'm pretty sure Eshell 
> doesn't even allow inspecting this value (yet), since it would only 
> occur for a non-last item in a pipeline. (In the future, Eshell could 
> offer something like $PIPESTATUS to examine this.)

Not sure I understand completely what you are saying here, but AFAIR
writing to a closed pipe on MS-Windows will cause EINVAL errno.

> I could expand the comment to explain that this value is 
> somewhat-arbitrary and just designed to match GNU/Linux.

Yes, please.

> Alternately, if there's a way to inspect the system's conventions to
> use here (e.g.  getting the numeric value of SIGPIPE for the current
> system), we could do that too.

I might be able to help if I understand better what is needed here.

Thanks.