bash programmable completion is not loaded in subshells when running a login shell

Status changed to 'Confirmed' because the bug affects multiple users.

Trusty is affected too.

Is this still the case that a default install of Ubuntu doesn't enable programmable completion out of the box? Not much point making bash-completion a standard-priority package if it's not enabled by default.

 my /etc/bash.bashrc still has the lines
# if [ -f /usr/share/bash-completion/bash_completion ]; then
# . /usr/share/bash-completion/bash_completion
# elif ...
 there but commented out (since I've had my and other users' ~/.bashrc source it for years).

As discussed in bug 790043 (about the slowdown of loading completions), the out-of-the-box configuration seems to be to load programmable completions (progcomp) for login shells, but not for non-login shells (e.g. bash in an xterm).

TL:DR summary: ~/.bashrc should source /etc/profile.d/bash_completion.sh

 This is mind-bogglingly silly, and would be confusing except that desktop users pretty much never run a login shell ever. Only with sudo --login, probably, or if they happen to configure gnome-terminal to start a login shell. People logging in with ssh to an Ubuntu machine will get progcomp in their login shell, but not in subshells they start inside screen(1), for example.

 The out-of-the-box shipped /etc/profile is
trusty: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/base-files/trusty/view/head:/share/profile
vivid-proposed: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/base-files/vivid-proposed/view/head:/share/profile

The out-of-the-box /etc/bash.bashrc is:
trusty-updates: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/bash/trusty-updates/view/head:/debian/etc.bash.bashrc
vivid-proposed: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/bash/vivid-proposed/view/head:/debian/etc.bash.bashrc

The out-of-the-box /etc/skel/.bashrc is:
vivid-proposed: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/base-files/vivid-proposed/view/head:/share/dot.bashrc

All this adds up to (in order of action for a login shell):
/etc/profile.d/bash_completion.sh : (from /etc/profile) source progcomp after checking it it's already loaded
~/.profile : nothing
-- Non-login shells start here
/etc/bash.bashrc : commented-out sourcing of progcomp (no check for already loaded)
~/.bashrc (from /etc/skel/.bashrc at adduser time): commented-out sourcing of progcomp (no check for already loaded)

In a login shell, /etc/profile sources /etc/bash.bashrc, and the default ~/.profile sources ~/.bashrc. (In both cases, after checking that the shell is bash). So login shells get everything that non-login shells do, plus whatever you put in profile to do once-per-login things, and/or to set env vars (which are inherited by non-login shells, and so don't need to be set again for every non-login shell.)

 My vote is to have ~/.bashrc source /etc/profile.d/bash_completion.sh (checking only that it exists, to not clutter up the user's file, because that file checks if bash_completion was already loaded.)

 There are mechanisms to check if bash_completion has already been sourced, so we can avoid taking the speed-hit of doing it twice. Any system rc file should check first before sourcing, because having bash_completion itself refuse to be re-sourced is problematic. (what if a user wants to do it manually?)

/etc/profile.d/bash_completion.sh (shipped by bash-completion) checks on -z "$BASH_COMPLETION_COMPAT_DIR", which the giant bash_completion script defines (and makes readonly, meaning it can't ever be unset). So I guess BASH_COMPLETION_COMPAT_DIR is the canonical way to check if it's already loaded.

 A better check might be if ! complete -p paste > /dev/null; then source it; fi, because upstream hopes to even...

So to be clear, the changes I'm suggesting are:

* /etc/skel/.bashrc (pkg=base-files) change the progcomp check to an un-commented
# enable programmable completion
[[ -e /etc/profile.d/bash_completion.sh ]] && . /etc/profile.d/bash_completion.sh

* /etc/bash.bashrc (pkg=bash): remove the progcomp commented-out section, maybe replace with a comment like:
# enable programmable completion with this line, here or (default) in ~/.bashrc
# [[ -e /etc/profile.d/bash_completion.sh ]] && . /etc/profile.d/bash_completion.sh

Root's /root/.bashrc doesn't come into play on an ubuntu system, normally. Even if you use sudo -s, HOME doesn't change, so you still get your own ~/.bashrc

If you're mucking around with testing corner cases, put
echo "bash_completion callstack: ${BASH_SOURCE[*]}"
 in /usr/share/bash-completion/bash_completion to get output like
bash_completion callstack: /usr/share/bash-completion/bash_completion /etc/profile.d/bash_completion.sh /home/peter/.bashrc

 Or drop that line into /etc/bash_completion.d/trace, if you don't want to modify a non-conffile.

Could you clarify the issue for me and provide a test case?

You said that "desktop users pretty much never run a login shell ever." Am I right that running gnome-terminal in Unity by pressing Ctrl + Alt + T is running a non-login shell?

I tried to clarify the summary based on this comment: "People logging in with ssh to an Ubuntu machine will get progcomp in their login shell, but not in subshells they start inside screen(1), for example."

Let me know if I made a mistake.