Ian Wienand <iwienand@xxxxxxxxxx> writes:
> diff --git a/run-command.c b/run-command.c
> index 1b821042b4..9892c4421c 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -746,6 +746,8 @@ int start_command(struct child_process *cmd)
> goto end_of_spawn;
> }
>
> + trace_argv_printf(&argv.v[1], "trace: start_command:");
> +
> if (pipe(notify_pipe))
> notify_pipe[0] = notify_pipe[1] = -1;
This side is OK ...
> @@ -913,6 +915,7 @@ int start_command(struct child_process *cmd)
> else if (cmd->use_shell)
> cmd->args.v = prepare_shell_cmd(&nargv, sargv);
>
> + trace_argv_printf(&cmd->args.v[1], "trace: start_command:");
> cmd->pid = mingw_spawnvpe(cmd->args.v[0], cmd->args.v,
> (char**) cmd->env.v,
> cmd->dir, fhin, fhout, fherr);
... but this side should pass "cmd->args.v" (i.e., the entire array,
without omitting the zeroth element) to be consistent with the other
side. I made the same mistake in my "how about doing it this way"
draft, by the way.
It is because prepare_cmd() does this:
static int prepare_cmd(struct strvec *out, const struct child_process *cmd)
{
...
/*
* Add SHELL_PATH so in the event exec fails with ENOEXEC we can
* attempt to interpret the command with 'sh'.
*/
strvec_push(out, SHELL_PATH);
if (cmd->git_cmd) {
prepare_git_cmd(out, cmd->args.v);
} else if (cmd->use_shell) {
prepare_shell_cmd(out, cmd->args.v);
...
So, the other side (i.e. non Windows, that used the result from
prepare_cmd()) skips the argv.v[0] element (which is the SHELL_PATH
pushed by prepare_cmd()), but because a bare use of
prepare_shell_cmd() done on the Windows side does not have that
excess element at the beginning.
