问题
I have found that shopt -s nullglob apparently disables tab-completion for files and directories, and shopt -u nullglob restores it. Why does tab-completion for directories apparently rely on nullglob being unset?
I am using Bash 4.2.37(1)-release on Debian 7.
回答1:
This is apparently a known issue with bash-completion and is listed as an objective to be fixed in the 3.0 version.
But apparently it has been that way since at least 2012.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666933 for reference.
Edit: At least 2011: http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/3652
I do not at all understand how nullglob causes the problem listed in that email though.
Edit: I now understand what is happening. The problem is that glob expansion is dumb. It sees the entire "word" $2[$j]=\${!ref}\${COMP_WORDS[i]} as a single glob and tries to expand it. Normally that fails and it gets left alone but will nullglob on that entire argument simply vanishes (thus causing the problem).
Quick testing indicates that replacing this:
eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
with either:
eval $2\[$j\]=\${!ref}\${COMP_WORDS\[i\]}
or:
eval "$2[$j]=\${!ref}\${COMP_WORDS[i]}"
seems to fix the problem. I can't vouch for either of those being a fully correct fix though.
Update: This is fixed in the debian bash-completion git repository already (in a way I hadn't thought of but which is clearly better).
This commit fixes it. There are other globbing related fixes too.
Grabbing the __reassemble_comp_words_by_ref from git head and sourcing that on top of the current one appears to fix the problem as a temporary workaround/solution.
来源：https://stackoverflow.com/questions/29907892/nullglob-disables-pathname-tab-completion