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

[Philipp Stephani]

Am Do., 14. Mai 2020 um 16:07 Uhr schrieb Noam Postavsky <npostavs@gmail.com>:
>
> Philipp Stephani <p.stephani2@gmail.com> writes:
>
> > Am Do., 14. Mai 2020 um 13:00 Uhr schrieb Michael Albinus
> > <michael.albinus@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.