touch-packages team mailing list archive

[Peter Cordes <peter@xxxxxxxxx>]

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 eventually get rid of
/etc/bash_completion.d.  But it will probably never happen.

 None of this helps if profile.d goes first, and then a user's ~/.bashrc
sources completions without checking, though.  That's why I vote for
modifying /etc/skel/.bashrc, rather than adding it by default to
/etc/bash.bashrc.  It can't result in extra sourcing of completions for
existing installs, because it's just the template for new accounts.

 Also, if /etc/bash.bash sources it, then admin users can't avoid the
performance hit of having it load.

 I think the default ~/.bashrc is a really obvious place to put the
default setting for a bash-specific shell feature that individual users
might want to config differently.

 It's also not going to change anything for people upgrading existing
installs that already work the way they like.  All we lose out on is
giving progcomp to people who didn't even know it existed, when they
upgrade.  Any way to do that has downsides that I think are worth
avoiding for the long term.  Except by writing a tool to check if the
users is missing out on progcomp for non-login shells, and ask them if
they want to enable it, and then tack lines on to their ~/.bashrc.  I
know do-release-upgrade runs helper scripts that help deal with changes,
would that be an appropriate place to put that kind of check?  Or should
it not be touching anything under /home?


** Also affects: base-files (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to base-files in Ubuntu.
https://bugs.launchpad.net/bugs/1173728

Title:
  bash programmable completion not loaded by default

Status in base-files package in Ubuntu:
  New
Status in bash-completion package in Ubuntu:
  Confirmed

Bug description:
  I don't know it's bug or feature, but [TAB] autocomplete won't work
  with sudo on 13.04 (and 12.10 too). To fix this, you need to uncomment
  some lines in /etc/bash.bashrc and then [TAB] autocomplete will work.

  http://askubuntu.com/questions/209778/auto-completion-does-not-work-
  for-sudo-apt-get-install

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: bash 4.2-5ubuntu3
  ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8
  Uname: Linux 3.8.0-19-generic x86_64
  NonfreeKernelModules: fglrx
  ApportVersion: 2.9.2-0ubuntu8
  Architecture: amd64
  Date: Sat Apr 27 22:03:33 2013
  InstallationDate: Installed on 2013-04-26 (1 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  MarkForUpload: True
  SourcePackage: bash
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1173728/+subscriptions