Am 12.01.22 um 19:34 schrieb René Scharfe: > > Am 12.01.22 um 18:50 schrieb Junio C Hamano: >> René Scharfe <l.s.r@xxxxxx> writes: >> >>> It would be nice if we could determine if the command was not found by >>> the shell and halt the bisection. This is actually indicated by the >>> shell using error code 127. However, the script itself could also exit >>> with that code (e.g. if one of its commands was not found). Currently >>> this is interpreted as a bad revision and bisection continues, as >>> documented in the man page of git bisect. >>> >>> If we'd make error code 127 (and 126) special by stopping the bisection >>> (like we do for 128 and higher) then scripts that relied on that code >>> indicating a bad revision would require a manual "git bisect bad" at >>> each affected step. Annoying, but not dangerous. Such a script would >>> have to be modified to convert codes 126 and 127 to e.g. 1. >>> >>> Seems like a reasonable trade-off to me. Thoughts? >> >> Probably. It is safer than the current "all revisions including the >> bottom one and the top one are bad" which leads to the "merge-base >> says your good and bad are nonsense" error for the "command not >> found" case, but what if the one that reports an error with 127 (or >> 126) is coming from something other than shell (i.e. the 'bisect >> run' command was fed is not a script at all)? Is it a no-no for a >> random binary that is not an implementation of shell to exit with >> these error status? > > The man page of exit(3) mentions the implementation-defined constants > EXIT_SUCCESS and EXIT_FAILURE from C99. It also says: "Cooperating > processes may use other values". > > sysexits(3) on BSD mentions a few others, all below 100 > (https://man.openbsd.org/sysexits.3). Its BUGS section says: > "The choice of an appropriate exit value is often ambiguous.". > > So exit code values are only very vaguely standardized. It's very > possible that there are programs that use 126 or 127 to signal > something other than "can't execute" or "cannot find command". Under > the new rules the bisect run script would have to translate them to > some lower value. Reserving 126 and 127 shouldn't cause too much trouble, but there's also a way to avoid it: bisect run could checkout a known-good revision first and abort if the script returns non-zero for any reason, including its non-existence. René
