Expanding variables on command line does not work in version 2.4

[scop]

Expanding variables on command line does not work in version 2.4

[bitstreamout]

With echo as command it works ... it does not work with e.g. mkdir

[akinomyoga]

The problem doesn't seem to reproduce in the current version.

[scop]

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.

[akinomyoga]

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 filenames is specified to the completion setting and the completion function generates a parameter expansion of the form $varname. However, -o filenames is specified to the ls completion 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 filenames and 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.d and 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.

[scop]

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.