René Scharfe wrote:
> Am 13.01.22 um 13:28 schrieb Christian Couder:
> > I don't think it's a good idea at this point to reserve the 126 and
> > 127 error codes as there might be existing scripts relying on them
> > to mean "bad".
>
> Certainly possible -- people get the weirdest ideas.
My gut reaction is that this is an overly conservative point of view. There are two factors to consider: first, bisect scripts are usually short one-time throwaway scripts tailored to one project for one problem. Second, how likely is it that these people that have a complex script with 126/127 as the exit code, which they have been using for years to run bisect on the same project for the same problem, update their version of git frequently?
Again, I might be wrong, because I don't know how people use bisect. Worst case, we can display a warning about this backward incompatibility in the next few versions.
> The implementation language of git bisect is not immediately relevant
> here, but that the shell is used to call the user-supplied bisect run
> script is. If we'd run it directly (without RUN_USING_SHELL) we could
> distinguish error code 126/127 from execution errors. I assume the
> option is used to stay compatible with the old shell version of bisect.
Sorry, my misunderstanding. I thought the external command was being called from git-bisect.sh. I don't think I understand the purpose of RUN_USING_SHELL (it just seems to put an "sh -c" in the beginning):
static const char **prepare_shell_cmd(struct strvec *out, const char **argv)
{
...
strvec_push(out, "sh");
strvec_push(out, "-c");
if (!argv[1])
strvec_push(out, argv[0]);
else
strvec_pushf(out, "%s \"$@\"", argv[0]);
...
}
Warm regards,
Ram
