[Bash-completion-devel] New directory layout

David Paleino d.paleino at gmail.com
Fri Jan 16 19:08:02 UTC 2009

On Tue, 13 Jan 2009 02:16:51 +0100, Santiago M. Mola wrote:

> Hi all,

Hello Santiago, hello all,

> Based on the current aproach on Gentoo and on comments from other
> distros, I'd like to propose a new directory layout for bash-completion.

Ok, let's see :-)

> El lun, 12-01-2009 a las 23:55 +0100, Guillaume Rousse escribió:
> > We also have a slightly initialisation system, with a file
> > in /etc/profile.d sourcing a system-wide /etc/sysconfig/bash-completion
> > configuration file, then a ~/.bash-completion to set up relevant
> > options. This let sysadmin configure bash completion globally, or not,
> > while still allowing individual users to do it in the last case.
> In Gentoo, we install all bash-completion modules
> to /usr/share/bash-completion/.

In Debian, we have them in /etc/bash_completion - /etc/bash_completion.d/. But,
since those are not really configuration files, and are rather arch-independent
data, I'd vote for those to go to /usr/share/bash-completion/. +1 for Gentoo ;-)

> Modules are enabled system-wide when they're symlinked
> from /etc/bash_completion.d/ and users can enable extra modules creating
> symlinks in ~/.bash_completion.d/.
> We have a Gentoo-specific tool for handling these symlinks, but I guess
> each distro would take its own aproach, which could be a) providing a
> configuration interface, b) enabling all modules by default (like some
> already do), c) let the user do it himself. 

I really like the idea of per-user completions, read further on my reply to

However, the symlinks-in-/etc/bash_completion.d/ approach doesn't seem very
robust, either. In Debian we have "alternatives", i.e. symlinks for executables
(generally speaking, also for libraries) in /etc/alternatives/ pointing
to /usr/bin/foo or /usr/lib/libfoo.so. Said that, I can't see how we (Debian)
could sanely handle that with our "distribution-specific tool". Maybe we could
also provide some distribution-agnostic tool to handle those symlinks?
(something like a2ensite and a2enmod for apache2 -- but I don't really know
whether those are Debian-specific)

> I think installing modules to /usr/share/bash-completion is more
> consistent than the current state (I don't think bash-completion modules
> can be considered anything near to configuration files).


> Also, this provides more flexibility for distros and users. And it seems
> it's needed since enabling/disabling modules system and user wide is a
> quite common demanded feature.


> With respect backwards compatibility, there's not too much to say: if
> someone installs a module directly to /etc/bash_completion.d, it'll
> obviously work.



 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20090116/53f4b1ca/attachment.pgp 

More information about the Bash-completion-devel mailing list