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