1

On my Ubuntu 14.04.3 machine with enabled bash completion (through . /etc/bash_completion in ~/.bashrc), I do not get directory-content completion for cmd --param=<TAB>, i.e., nothing is happening when pressing . When I start a pristine bash (e.g. through env -i bash --norc), it works as expected -- but then no programmable completion is available. I found Bash completion for path in argument (with equals sign present) which talks about a similar issue but 1) the respective npm script is not existing on my machine and 2) even removing all files from /etc/bash_completion.d does not fix the problem. What can I do to get proper completion?

I found one halfhearted fix by running complete -r -D which prevents bash from trying to complete new commands. This enables completion after equals again, but stops completion, for example, for killall.

Community
  • 1
  • 1
tlangner
  • 11
  • 1
  • Does `$COMP_WORDBREAKS` include an `=`? If not, try `COMP_WORDBREAKS+==` and see if completion does what you expect. – rici Aug 14 '15 at 14:14
  • The content of $COMP_WORDBREAKS is `"'><=;|&(:`. Removing or adding `=` does not seem to change the behavior wrt. completion after `=`, unfortunately. – tlangner Aug 17 '15 at 07:15
  • Run `complete -p cmd` and see if there's a compspec defined for your *cmd*. – pynexj Aug 17 '15 at 08:11
  • No, there is no specific compspec defined, it does not complete properly for any command (last time I used `ljkasdfjler --asdlk=` ;) ) – tlangner Aug 18 '15 at 11:27

1 Answers1

0

While I do not understand what you mean by "stops completion after killall", I believe there is a workaround.

I found it here. It involves overriding a broken bash completion function. Copy-pasting here for the record. The workaround is to add the following to your .bashrc:

_completion_loader () {
  local dir=/usr/share/bash-completion/completions
  local cmd="${1##*/}"
  . "${dir}/${cmd}" &>/dev/null && return 124
  complete -o default -o bashdefault "${cmd}" &>/dev/null && return 124
}

I am uncertain whether the actual reported bug is fixed in bash: the comments in the bug report are unclear and mention a couple more problems. For the record, my bash is version 4.2.46(1)-release (Redhat EL 7) which does have this bug.

ST0
  • 195
  • 2
  • 11