Subject: Re: bug#41099: 28.0.50; TRAMP process-file ignores exit status of remote process

From: Michael Albinus <[email-masked]>
Date: Thu, 14 May 2020 13:00:44 +0200

Noam Postavsky <[email-masked]> writes:

Hi Noam,

>>> (defun tramp-process-file (...)
>>>   (let ((code (...original code...)))
>>>     (if (> code 128)
>>>        ;; Probably a signal
>>>        (format "Signal %d" (- code 128))
>>>     code))
>>
>> I've pushed a patch to master along these lines.
>
> I don't think this is sufficiently reliable.  With current master:
>
>     (let ((default-directory "/sudo::/home/npostavs/.emacs.d/"))
>       (process-file "git" nil nil nil "merge-base"))
>     ;=> "Signal 1"
>
>     (let ((default-directory "/home/npostavs/.emacs.d/"))
>       (process-file "git" nil nil nil "merge-base"))
>     ;=> 129

I see. A short test shows, that git is using exit code 129 in case of
error in invocation, although it isn't documented in the man pages.

Hmm, this seems to be a contradiction to the specification of reserved
exit codes, as described in <https://tldp.org/LDP/abs/html/exitcodes.html>.
We cannot change git, so either

- we keep Tramp's process-file implementation as it is,
- we don't return a string in case a signal has interrupted the process,
- we install trap handlers in the remote shell in order to let Tramp
  detect signals reliably.

The last alternative might be the best approach to keep the process-file
spec. But it sounds expensive to me, and people already complain about
Tramp performance. Do we want to go this way?

Best regards, Michael.