Ville Skyttä <ville.skytta@xxxxxx> writes:
> Subject: [PATCH] Abort early if not being sourced under bash.
>
> This way, the file can be safely sourced from profile files shared with
> non-bash shells, eg. dropped into /etc/profile.d like directories.
>
> Signed-off-by: Ville Skyttä <ville.skytta@xxxxxx>
> ---
> contrib/completion/git-completion.bash | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 4ea727b..3cde9f4 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -45,6 +45,8 @@
> # git@xxxxxxxxxxxxxxx
> #
>
> +[ -z "$BASH_VERSION" ] && return
> +
> __gitdir ()
> {
> if [ -z "$1" ]; then
I do not particularly sympathize with the /etc/profile.d/
argument. Ditros can and should put a small script in there
that checks what /bin/sh it really is running and source the
real thing from elsewhere, perhaps /usr/share/git-core/,
appropriately.
However, even if you did so, there is another issue. One of my
hosts have a bash that does not know the "complete" command, and
logging into the host I get twenty-or-so "bash: complete:
command not found".
So
if bash "complete" would not work for this shell
then
__git_ps1 () { : dummy; }
return
fi
at the beginning may be needed even if you know we are running
bash.
Then people can safely say:
PS1=': \h \W$(__git_ps1 "/%s"); '
(or whatever git-completion.bash suggests these days) in their
start-up script.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
