Re: esh-proc test failures

[Jim Porter <jporterbugs@gmail.com>]

On 8/22/2022 11:56 AM, Eli Zaretskii wrote:
>> From: Jim Porter <jporterbugs@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 22 Aug 2022 10:06:36 -0700
>>
>> diff --git a/lisp/eshell/esh-cmd.el b/lisp/eshell/esh-cmd.el
>> index 2f77f3f497..d5cc3706fd 100644
>> --- a/lisp/eshell/esh-cmd.el
>> +++ b/lisp/eshell/esh-cmd.el
>> @@ -1347,6 +1347,10 @@ eshell-exec-lisp
>>                    (apply func-or-form args)))))
>>           (and result (funcall printer result))
>>           result)
>> +    (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. 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.)

I could expand the comment to explain that this value is 
somewhat-arbitrary and just designed to match GNU/Linux. 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.