Re: [PATCH v6 04/11] run-command: use the async-signal-safe execv instead of execvp

> 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.
> 
> -Peff