Re: [PATCH 1/2] help: add shell-path to --build-options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020-05-12 at 23:42:12, Emily Shaffer wrote:
> It may be useful to know which shell Git was built to try to point to,
> in the event that shell-based Git commands are failing. $SHELL_PATH is
> set during the build and used to launch the manpage viewer, as well as
> by git-compat-util.h, and it's used during tests. 'git version
> --build-options' is encouraged for use in bug reports, so it makes sense
> to include this information there.
> 
> Signed-off-by: Emily Shaffer <emilyshaffer@xxxxxxxxxx>
> ---
>  help.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/help.c b/help.c
> index 1de9c0d589..44cee69c11 100644
> --- a/help.c
> +++ b/help.c
> @@ -641,6 +641,7 @@ void get_version_info(struct strbuf *buf, int show_build_options)
>  			strbuf_addstr(buf, "no commit associated with this build\n");
>  		strbuf_addf(buf, "sizeof-long: %d\n", (int)sizeof(long));
>  		strbuf_addf(buf, "sizeof-size_t: %d\n", (int)sizeof(size_t));
> +		strbuf_addf(buf, "shell-path: %s\n", SHELL_PATH);
>  		/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
>  	}
>  }

This seems straightforward and logical (as does the rest of the series),
but I wondered if it might be a good idea to try to interrogate the
shell for more information.  The reason I mention it is that Debian
permits any shell that meets certain standards to be /bin/sh, and all
programs that invoke /bin/sh must depend on only those features.  The
default is dash, but people could use bash, which is more featureful, or
posh, which is intentionally designed to provide the bare minimum
/bin/sh experience[0], among others.  A value of "/bin/sh" doesn't
necessarily tell us very much on Debian (or on macOS, for that matter).

Now, that of course does mean that we have to have some way to
distinguish between shells, and that is the hard part, so I'm completely
fine with us leaving it out until we have a good way to do it (or until
we decide we need it, which may be never).  I just wanted to mention it
as a potential approach for the future.  I'm happy with this series as
it stands right now.

[0] Quite literally, in that it's supposed to be a tool for testing
compatibility with the policy requirements.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux