Re: [PATCH v5] completion: add new __git_complete helper

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

 



On Mon, May 14, 2012 at 8:13 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>>>> +__git_func_wrap ()
>>>> +{
>>>> +     if [[ -n ${ZSH_VERSION-} ]]; then
>>>> +             emulate -L bash
>>>> +             setopt KSH_TYPESET
>>>> +
>>>> +             # workaround zsh's bug that leaves 'words' as a special
>>>> +             # variable in versions < 4.3.12
>>>> +             typeset -h words
>>>> +
>>>> +             # workaround zsh's bug that quotes spaces in the COMPREPLY
>>>> +             # array if IFS doesn't contain spaces.
>>>> +             typeset -h IFS
>>>> +     fi
>>>> +     local cur words cword prev
>>>> +     _get_comp_words_by_ref -n =: cur words cword prev
>>>> +     $1
>>>> +}
>>>> +
>>>> +# Setup completion for certain functions defined above by setting common
>>>> +# variables and workarounds.
>>>> +# This is NOT a public function; use at your own risk.
>>>> +__git_complete ()
>>>> +{
>>>> +     local wrapper="__git_wrap${2}"
>>>> +     eval "$wrapper () { __git_func_wrap $2 ; }"
>>>> +     complete -o bashdefault -o default -o nospace -F $wrapper $1 2>/dev/null \
>>>> +             || complete -o default -o nospace -F $wrapper $1
>>>> +}
>>>> +
>>>> +__git_complete git _git
>>>> +__git_complete gitk _gitk
>>>
>>> It makes my stomach queasy whenever I see $var not in double quotes that
>>> forces me to guess (and trace to verify if the codepath is what I really
>>> care about) if any value with $IFS in it could be used there, so even when
>>> they are known to be safe, I'd prefer to see either explicit quotes or
>>> comment that says what are expected in $1 and $2.
>>
>> Which ones?
>
> All of them ;-)
>
> Here is my attempt to explain why none of them needs to be quoted:
>
>  # Setup completion for certain functions defined above by setting common
>  # variables and workarounds.
>  # It takes two parameters:
>  #  - the first is the command name on the command line to complete its
>  #    arguments for the user;
>  #  - the second is a name of the completion function
>  # This is NOT a public function; use at your own risk.
>  #
>  # Note that none of the variable reference in the implementation of this
>  # function needs dq around it.

I don't understand that.

>  # wrapper: the name of an internal shell function that wraps the
>  #          completion function $2, formed by prefixing "__git_wrap"
>  #          in front of it.  As it has to be usable as a name of a
>  #          shell function, by definition there won't be $IFS characters
>  #          in it.
>  # $1:      the command name on the command line---ditto.
>  # $2:      the shell function name that implements the completion-ditto.

So in short; because the variables are used as function/command names.

Cheers.

-- 
Felipe Contreras
--
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


[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]