From: Jeff King <peff@peff.net>
Date: Wed, 17 May 2017 02:26:02 GMT
Subject: Re: [PATCH v6 04/11] run-command: use the async-signal-safe execv instead of execvp
Message-ID: <20170517022602.jj26pf7eypxp2fjm@sigill.intra.peff.net>
In-Reply-To: <xmqqfug4z0s0.fsf@gitster.mtv.corp.google.com>

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