On Tue, May 16, 2017 at 10:26:02PM -0400, Jeff King wrote: > On Wed, May 17, 2017 at 11:15:43AM +0900, Junio C Hamano wrote: > > > > + if (errno == ENOEXEC) > > > + execv(argv.argv[0], (char *const *) argv.argv); > > > > "/bin/sh" tries to run "/usr/bin/git" that was not executable (well, > > the one in "usr/bin/" would have +x bit, but let's pretend that we > > are trying to run one from bin-wrappers/ and somehow forgot +x bit)? > > > > I think all of that is sensible, but there is one "huh?" I can't > > figure out. Typically we do "sh -c git cat-file -t HEAD" but this > > lacks the "-c" (cf. the original prepare_shell_cmd()); why do we not > > need it in this case? > > I think this is the same case we were discussing over in the "rebase" > thread. This isn't about running the user's command as a shell command. > Note that this kicks in even when cmd->shell_cmd isn't set. > > This is about finding "/usr/bin/foo", realizing it cannot be exec'd > because it lacks a shebang line, and then pretending that it did have > "#!/bin/sh". IOW, maintaining compatibility with execvp(). > > So the command itself isn't a shell command, but it may execute a shell > script. If that makes sense.
And note that this isn't about the "+x" bit. That would result in EACCES. Getting ENOEXEC means that the contents of the binary are not something execv thought it could run. -Peff
