zsh autocompletion not replacing tabs correctly #105587
Description
What happened?
While using zsh autocompletion:
[fandahao@localhost]~% kubectl ge\tNo completion result is given.
When I turn on $BASH_COMP_DEBUG_FILE, I see the following logs:
========= starting completion logic ==========
CURRENT: 2, words[*]: kubectl ge
Truncated words[*]: kubectl ge,
lastParam: ge, lastChar: e
About to call: eval kubectl __complete ge
completion output: get Display one or many resources
:4
last line: :4
directive: 4
completions: get Display one or many resources
flagPrefix:
Adding completion: :g:e:t: :D:i:s:p:l:a:y: :o:n:e: :o:r: :m:a:n:y: :r:e:s:o:u:r:c:e:s
I noticed that the last line seems to give weird results. After printing out what source <(kubectl completion zsh) does, I think the bug is caused by the following lines:
# If requested, completions are returned with a description.
# The description is preceded by a TAB character.
# For zsh's _describe, we need to use a : instead of a TAB.
# We first need to escape any : as part of the completion itself.
comp=${comp//:/\\:}
local tab=$(printf '\t')
comp=${comp//$tab/:}The last line is supposed to replace all \t's in the completion result with :, but it actually replaced all empty strings with a :.
Replacing the last two lines with the following code seems to solve the problem:
comp=${comp//$(printf '\t')/:}Honestly, I don't know why this works correctly while the original code does not. I guess tabs may need to be treated differently when doing variable expansions?
What did you expect to happen?
After modifying the code as in last section, I got the following logs. I think this is the correct result.
========= starting completion logic ==========
CURRENT: 2, words[*]: kubectl ge
Truncated words[*]: kubectl ge,
lastParam: ge, lastChar: e
About to call: eval kubectl __complete ge
completion output: get Display one or many resources
:4
last line: :4
directive: 4
completions: get Display one or many resources
flagPrefix:
tab is ''
Adding completion: get:Display one or many resourcesHow can we reproduce it (as minimally and precisely as possible)?
[fandahao@localhost]~% zsh --version
zsh 5.0.2 (x86_64-redhat-linux-gnu)A minimal .zshrc:
source <(kubectl completion zsh)Anything else we need to know?
No response
Kubernetes version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"c2b5237ccd9c0f1d600d3072634ca66cefdf272f", GitTreeState:"clean", BuildDate:"2021-08-04T18:03:20Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"c2b5237ccd9c0f1d600d3072634ca66cefdf272f", GitTreeState:"clean", BuildDate:"2021-08-04T17:57:25Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
Cloud provider
This bug happens on my own machine.
OS version
[fandahao@localhost]~% cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
[fandahao@localhost]~% uname -a
Linux localhost.localdomain 5.4.146-1.el7.elrepo.x86_64 #1 SMP Tue Sep 14 08:38:01 EDT 2021 x86_64 x86_64 x86_64 GNU/Linux