Bash completion slowing down login

From FVue
Jump to: navigation, search


On my Linux box (Ubuntu 7.10) – powered by an AMD K7 500 MHz processor – the loading of bash completion is taking a considerable long time. For example, with the following lines commented in /etc/bash.bashrc:

#if [ -f /etc/bash_completion ]; then
#    . /etc/bash_completion

this is how long it takes to load bash completion:

$> time . /etc/bash_completion

real    0m0.876s
user    0m0.728s
sys     0m0.096s

This is because bash-completion loads all completions at once. This is >200 Kb containing completion for >120 commands. But what if I don't need completion for all commands? On average I guess I'm only using 1% of the available completion functions, but still all of bash-completion is loaded every time I login. Wouldn't it be beneficial for both speed and resources if specific completions would load only if explicitly invoked?

Solution 1. Use bash-completion-lib

Bash-completion-lib is a modular rewrite of bash-completion, and is 5 times as fast.

See: Bash_completion_library

Solution 2. Make restricted completion optional

Apply the patch underneath to /etc/bash_completion. This will introduce an additional variable `BASH_COMPLETION_DO_RESTRICT' default set to false (0). If true (1), restricted completion will be invoked.

--- bash_completion.orig    2008-01-19 09:51:31.000000000 +0100
+++ bash_completion 2008-01-19 11:19:55.000000000 +0100
@@ -34,8 +34,9 @@
   # readonly variable errors.
 } 2>/dev/null || :
 # Set a couple of useful vars
@@ -77,6 +78,7 @@
 # The following section lists completions that are redefined later
 # Do NOT break these over multiple lines.
+if (( ${BASH_COMPLETION_DO_RESTRICT-0} )); then
 # START exclude -- do NOT remove this line
 complete -f -X '!*.?(t)bz?(2)' bunzip2 bzcat bzcmp bzdiff bzegrep bzfgrep bzgrep
 complete -f -X '!*.@(zip|ZIP|jar|JAR|exe|EXE|pk3|war|wsz|ear|zargo|xpi|sxw|ott)' unzip zipinfo
@@ -116,6 +118,7 @@
 complete -f -X '!*.odb' oobase
 complete -f -X '!*.rpm' rpm2cpio
 # FINISH exclude -- do not remove this line
 # start of section containing compspecs that can be handled within bash
@@ -9232,6 +9235,7 @@
 complete -F _svnlook $default svnlook
+if (( ${BASH_COMPLETION_DO_RESTRICT-0} )); then
    local IFS cur xspec
@@ -9276,6 +9280,7 @@
     eval complete -F _filedir_xspec $filenames ${list[@]}
 unset list
 # source completion directory definitions

An additional advantage is that sourcing bash completion will speed up by 30%:

$> time . /etc/bash_completion

real    0m0.556s
user    0m0.488s
sys     0m0.056s

For discussion why you want restricted completion to be disabled, see: Bug #94408 in bash (Ubuntu): “completion cleverness is fragile and hence stupid”



In the file bash_completion I can see the following function `have()':

# This function checks whether we have a given program on the system.
# No need for bulky functions in memory if we don't.
    unset -v have
    PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin type $1 &>/dev/null &&

This looks like a good feature of bash_completion: if a program isn't installed on your box, completion for the command will not be loaded. But still completion is loaded for every command I have installed, although I'm probably going to use only a minor subset of these commands in a typical bash session.


Blog entry of Behdad Esfahbod with interesting comments. Mr. Esfahbod is disabling bash completion in non-interactive shells. But the blog entry is of 2006: I think nowadays solution is to source bash_completion from /etc/bash.bashrc, which is only called in interactive shells...
Restricted tab-completion is annoying - Ubuntu-devel-discuss Archives
Newsgroup discussion about program-specific tab-completion, e.g. acroread completing only .pdf files


Bug #94408 in bash (Ubuntu): “completion cleverness is fragile and hence stupid”
Another complaint about bash completion in
SfR Fresh: Member bash_completion/TODO of archive bash-completion-20060301.t ...
From this TODO as of Mar-2006 it appears Ian McDonald - the current maintainer of bash completion - is looking for another maintainer


blog comments powered by Disqus