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

[Philipp Stephani]

Am Do., 14. Mai 2020 um 13:00 Uhr schrieb Michael Albinus
<michael.albinus@gmx.de>:
>
> Noam Postavsky <npostavs@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

We can at least file a bug against Git.

> so either
>
> - we keep Tramp's process-file implementation as it is,

I'd (naturally) prefer that way. Exit codes > 128 are nonportable, as
they don't allow shells to detect signals.

> - 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.
>

Maybe I'm missing something, but I don't understand how this could
work. Bash trap handlers only catch signals sent to the current
process, not to subprocesses:

$ trap 'echo SIGSYS caught' SYS
$ bash -c 'kill -SYS $$'
Bad system call: 12

Note that the trap handler isn't executed.