bash-completion
bash-completion copied to clipboard
Expanding variables on command line does not work in version 2.4
Simply do
export FOO=/tmp
ls $FO<TAB>
and see this
ls \$FOO/
or even with less
ls $F<TAB>
which results in
ls \$F
such TAB completion are very common and heavly used by many experienced users out here
With echo as command it works ... it does not work with e.g. mkdir
The problem doesn't seem to reproduce in the current version.
I wonder if this is a bash version thing; I cannot reproduce even with bash-completion version 2.4 any more, with bash 5.2.21(1)-release.
Hmm, I tried to reproduce the problem with different versions of Bash and bash-completion, but I still cannot reproduce the problem. On the other hand, the issue seemed to have been reported many times in the past with Bash <= 4.2. Maybe it happened with a specific set of options.
- I checked bash-completion-2.4 in Bash 4.1, 4.2, ..., 5.2, and the devel branch of Bash, but the problem doesn't seem to reproduce. I also tried Bash 4.0, but bash-completion-2.4 doesn't support Bash 4.0. I also tried
bash-completion-2.5, but the result seems to be the same. - #417 mentions bug-bash/2020-05/43, and a reply to it says it's fixed in Bash 4.2.29 while mentioning #323. However, the problem doesn't reproduce even with Bash 4.2.0 + bash-completion 2.4. One of the old reports seems to be reported with the combination of bash 4.2 and bash-completion-2.0
- The problem happens when
-o filenamesis specified to the completion setting and the completion function generates a parameter expansion of the form$varname. However,-o filenamesis specified to thelscompletion until bash-completion-1.3, while the completion of variable names is supported only from bash-completion-1.90. There doesn't seem to be a bash-completion version that has both-o filenamesand the variable name completions. One possibility is that a user loads different versions of bash-completion (e.g. the system bash-completion loaded via/etc/profile.dand the user's bash-completion installation directly sourced from .bashrc), but even in that case, the problem wouldn't happen because the one loaded later should overwrite everything the former one has defined.
I've run into this problem myself over the years multiple times, but at the moment I'm out of ideas how to attempt reproducing it. Will close now, I'm sure it will resurface if it is still present in some setup; hopefully we get all the needed info about it to get a reproducer.