Rick van Hattem <wo...@wol.ph> writes:
> The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check
> moot. The result (at least for me) is that zsh segfaults because of all the
> variables it's unsetting.
> ---
Overlong line, lack of sign-off.
> # Clear the variables caching builtins' options when (re-)sourcing
> # the completion script.
> -if [[ -n ${ZSH_VERSION-} ]]; then
> +if [[ -n ${ZSH_NAME-} ]]; then
I am not a zsh user, and I do not know how reliable $ZSH_NAME can be
taken as an indication that we are running zsh and have already
found a usable git-completion-.bash script.
I think what the proposed log message refers to as "unsets" is this
part of the script:
...
zstyle -s ":completion:*:*:git:*" script script
if [ -z "$script" ]; then
local -a locations
local e
locations=(
$(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
...
)
for e in $locations; do
test -f $e && script="$e" && break
done
fi
ZSH_VERSION='' . "$script"
...
If your ZSH_VERSION is empty, doesn't it indicate that the script
did not find a usable git-completion.bash script (to which it
outsources the bulk of the completion work)? I do agree segfaulting
is not a friendly way to tell you that your setup is lacking to make
it work, but I have a feeling that what you are seeing is an
indication of a bigger problem, which will be sweeped under the rug
with this patch but without getting fixed...
