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

Previous Next

Full log

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

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

Am Do., 14. Mai 2020 um 16:07 Uhr schrieb Noam Postavsky <npostavs <at> gmail.com>:
>
> Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>
> > Am Do., 14. Mai 2020 um 13:00 Uhr schrieb Michael Albinus
> > <michael.albinus <at> gmx.de>:
>
> >> 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.
>
> I don't think this is a correct description.  Bash has the convention
> that it uses codes > 128 to indicate commands terminated by signals.
> But processes other than bash (like git) don't necessarily follow this
> convention.  The shell can still detect the signals, it's shell
> *scripts* that will have the problem (when running commands that use
> exit codes > 128).

Yes, I mean scripts here. (TRAMP essentially runs a bunch of shell scripts.)
Since Unix binaries get invoked from shell scripts regularly, they
better behave in a predictable way. Bash scripts will regularly assume
that an exit code > 128 means termination by signal, so these binaries
are not portable in that sense.

>
> >> - we don't return a string in case a signal has interrupted the process,
>
> Since we don't have a reliable way to detect signals, I think this is
> the only viable option.

I'd expect the vast majority of programs to avoid such exit codes,
precisely because they would want to allow portable usage in shell
scripts. So I expect that the current behavior in master provides the
"correct" result in the majority of cases.

Previous Next

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