Re: [PATCH 2/2] help.c: use SHELL_PATH instead of hard-coded "/bin/sh"

[Junio C Hamano <gitster@pobox.com>]

"Kyle J. McKay" <mackyle@gmail.com> writes:

> If the user has set SHELL_PATH in the Makefile then we
> should respect that value and use it.
>
> Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
> ---
>  builtin/help.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/help.c b/builtin/help.c
> index 6133fe49..2ae8a1e9 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -171,7 +171,7 @@ static void exec_man_cmd(const char *cmd, const char *page)
>  {
>  	struct strbuf shell_cmd = STRBUF_INIT;
>  	strbuf_addf(&shell_cmd, "%s %s", cmd, page);
> -	execl("/bin/sh", "sh", "-c", shell_cmd.buf, (char *)NULL);
> +	execl(SHELL_PATH, SHELL_PATH, "-c", shell_cmd.buf, (char *)NULL);

It is a common convention to make the first argument the command
name without its path, and this change breaks that convention.

Does it matter, or would it break something?  I recall that some
implementations of shell (e.g. "bash") change their behaviour
depending on how they are invoked (e.g. "ln -s bash /bin/sh" makes
it run in posix mode) but I do not know if they do so by paying
attention to their argv[0].  There might be other fallouts I do not
think of offhand here.

I do not have an objection to what these patches want to do, though.

Thanks.

>  	warning(_("failed to exec '%s': %s"), cmd, strerror(errno));
>  }
>  
> ---