[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bash Auto Completion Fubar

From: Esben Stien
Subject: Bash Auto Completion Fubar
Date: Wed, 17 Jun 2009 20:39:29 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/22.0.92 (gnu/linux)

Dear bash help list members. I'm in serious need of help;). 

My problem deals with bash auto completion and the fact that it seems
to be a little random in addition to the fact that I run my own
distro, makes it a little hard to explain, as well, so bear with me.

Basically, I've been building and running my own distro, based on a
LFS core for many many years, without problems that were too hard to

Now I've stumped into a problem that nobody seems to have seen before
and I'm really stuck how to proceed. 

Right now, I'm building LFS-6.4, which includes bash-3.2:


This shouldn't really matter for you and you probably don't need to
know much about it, to help me debug my problem.

The problem is that sometimes bash auto completion works and sometimes
it doesn't.

I'm seeing the same problem with bash-3.2 and bash-4.0 when installing
the new system, but my previous LFS system, from 2006, which also has
bash-3.2.39, doesn't have this problem.


If I do 

tar -zxf file-4.26.tar.gz

..then I have one file and one directory named: 


If I try to cd into this directory: 

cd file TAB

..it auto completes the filename. 

It doesn't even see the directory.

If I do:

cd file* TAB

..it lists both the directory and the file, but if I want to enter the
directory, I have to write the complete directory and hit enter.

It's really, really weird and it doesn't always happen, just with some
files/directories. I can unpack 10 files and cd into them with no
problem, then suddenly I hit one that doesn't auto complete.

I've used bash for 10 years and I do know what to expect. 

I've made sure I don't have any programmable completions:

complete -r

..so "complete" returns nothing

This is the output of ''bind -v''

set bind-tty-special-chars on
set blink-matching-paren on
set byte-oriented off
set completion-ignore-case off
set convert-meta off
set disable-completion off
set enable-keypad off
set expand-tilde off
set history-preserve-point off
set horizontal-scroll-mode off
set input-meta on
set mark-directories on
set mark-modified-lines off
set mark-symlinked-directories off
set match-hidden-files on
set meta-flag on
set output-meta on
set page-completions on
set prefer-visible-bell on
set print-completions-horizontally off
set revert-all-at-newline off
set show-all-if-ambiguous off
set show-all-if-unmodified off
set visible-stats off
set bell-style none
set comment-begin #
set completion-prefix-display-length 0
set completion-query-items 100
set editing-mode emacs
set history-size 500
set keymap emacs

This is very frustrating, cause it makes it impossible to work with. 

It's worth mentioning that I'm seeing this in a chroot environment
(chapter 6), so it really can't be some kind of kernel problem, cause
my system works as it always has done.

Highly unlikely any other packages I've installed from that LFS book,
like libc, cause this 6.4 version is many months old and I've asked
the LFS mailing list, but no one has seen this issue before. 

I don't expect any of you to familiarize yourself with LFS. I only
need some help how to approach debugging this problem. I've attached
strace to the running bash process, but don't really know what to look

Of course, the next thing I will try, is to build the LFS core from
another system, cause maybe some files from my system has polluted the
LFS core build, somehow, even though this should be impossible when
looking at the LFS build procedure.

Any pointers that can help me debug this problem?. 

Esben Stien is b0ef@e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e 
           jid:b0ef@    n     n

reply via email to

[Prev in Thread] Current Thread [Next in Thread]