GNU bug report logs - #41099
28.0.50; TRAMP process-file ignores exit status of remote process

Previous Next

Full log

Message #66 received at 41099 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Philipp Stephani <p.stephani2 <at> gmail.com>, 41099 <at> debbugs.gnu.org
Subject: Re: bug#41099: 28.0.50; TRAMP process-file ignores exit status of
 remote process
Date: Thu, 14 May 2020 13:00:44 +0200

Noam Postavsky <npostavs <at> gmail.com> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.