[Bash-completion-devel] Bug#503691: bash-completion: does not complete files and directories as arguments

Drew Parsons dparsons at debian.org
Tue Aug 18 05:37:45 UTC 2009


I'm seeing this bug too, and it's extraordinarily irritating.  Certain
commands do not allow general filename completion to proceed.  Looks
like some commands have specified accessible files identified by file
suffix.  This is not appropriate in a unix-like environment and is
counterintuitive.

An example is opening a data file into OpenOffice Calc.  ASCII data
files will commonly have a .txt or .dat file suffix (or .out
or .output).  Typing 
$ oocalc <TAB>,
the existing data files are not prompted for completion.

With gnumeric, by way of comparison, 
$ gnumeric <TAB>
will complete, for instance, to
$ gnumeric datafile.dat

Test it yourself simply with "touch datafile.dat" in an empty directory.

There are other situations where tab completion behaves
counterintuitively, presumeably due to the same underlying mechanism.
The example I have in mind here is reading log files using zless.  I
habitually use zless instead of less because many files in /var/log, and
also text doc files in /usr/share/doc, are gzipped.  zless can equally
read both compressed and uncompressed text files (less can only read
uncompressed).

So reading, for instance /var/log/syslog.  It's uncompressed.  But when
I type
$ zless /var/log/sys<TAB>
instead of completing to /var/log/syslog as expected, bash tab
completiong instead gives
$ zless /var/log/syslog.
By putting in the . it's skipped past the most recent uncompressed log
file and only presents the older log files.  Actually in this example
it's even more complicated than compressed vs uncompressed.  With a
second <TAB> to show completions of /var/log/syslog., I get
$ zless /var/log/syslog.
syslog.1     syslog.3.gz  syslog.5.gz  syslog.7.gz  
syslog.2.gz  syslog.4.gz  syslog.6.gz

So /var/log/syslog.1 is offered, but it is uncompressed.
Only /var/log/syslog is missing in this example.

In general it seems something is wrong with bash-completions application
of file suffices. Perhaps it shouldn't use them at all, should allow any
file to be offered as an argument to any program (which is, in my
opinion, normal unix behaviour. File suffices are a microsoft windows
invention).

Drew








More information about the Bash-completion-devel mailing list