Re: [PATCH v2 1/3] completion: bash: add __git_have_func helper

> Am 29.12.20 um 18:08 schrieb Felipe Contreras:
> > This makes the code more readable, and also will help when new code
> > wants to do similar checks.
> >
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > ---
> >  contrib/completion/git-completion.bash | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > index 463a3124da..869c73ee2c 100644
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -3358,15 +3358,19 @@ __git_support_parseopt_helper () {
> >  	esac
> >  }
> >
> > +__git_have_func () {
> > +	declare -f $1 >/dev/null 2>/dev/null
> 
> I stumbled slightly over the lack of quoting.  It doesn't matter for
> the callers below, but new callers passing arbitrary strings could
> cause strange effects:
> 
> 	x() { echo x; }
> 	y() { echo y; }
> 	__git_have_func "x y" # succeeds
> 
> 	__git_have_func -a # succeeds
> 
> I just skimmed patch 3, but it seems to call __git_have_func with
> user-supplied strings, so this might become relevant.

> And then I wondered why use declare -f, which prints the function's
> body, when there is -F, which just prints the function's name.  And why
> repeat /dev/null when redirecting stderr when the more shorter 2>&1
> would do the same?  None of hat was introduced by you patch, of course.
> Anyway, this seems to work for me:
> 
> 	__git_have_func () {
> 		case "$1" in
> 		-*) return 1 ;;
> 		esac
> 		declare -F "$1" >/dev/null 2>&1
> 	}