[Bash-completion-devel] New directory layout

[David Paleino]

Hello Ville,

On Thu, 15 Jan 2009 23:18:16 +0200, Ville Skyttä wrote:

> Here's some food for thought:
> 
> The main script:
>     /usr/share/bash-completion/bash_completion

Oh well, if we move everything to /u/s/bash-completion/, calling it
"bash_completion" seems a bit redundant ;-)

We could rename it to "core", "base", or something suggesting *that* is the
main file.

> Directory where all the bundled modules are installed, all packages
> installing additional modules should also drop theirs here; bash_completion
> does *not* load anything from here:
>     /usr/share/bash-completion/modules/

Ok, let's see how you load "default" "modules" next.

> Per user config file, loaded by bash_completion (just like it does now):
>    ~/.bash_completion

Uh, I didn't know we were sourcing ~/.bash_completion ;-)
Jokes aside, that's really a good idea. But, probably, that one should be a
"configuration file" -- i.e. it shouldn't contain any completion itself, but
rather tell the "core" file what to load from ~/.bash_completion.d/
or /usr/share/bash-completion/modules.

> Directory for user to install/symlink additional modules to, bash_completion 
> loads everything from here:
>    ~/.bash_completion.d/

Well, if ~/.bash_completion is a configuration file, we could make the
user decide what to load and not from his per-user directory.

> Directory reserved for local sysadmins to symlink/install additional system 
> wide modules to (no packages should drop anything here), bash_completion 
> loads everything from here:
>    /etc/bash_completion.d/

Agreed, this ensures backwards-compatibility, as also Santiago pointed out.

> Directory where OS default modules (e.g. ones enabled at additional package 
> install time) are symlinked to, everything loaded by bash_completion; 
> sysadmins or users should not touch this dir or its contents.  Tools that 
> manage system wide modules should operate on these files, 
> not /etc/bash_completion.d/ ones:
>     /var/lib/bash-completion # or maybe bash[-_]completion.d ?

I don't really like /var/lib/ -- but I'd have to check FHS for any other
suitable directory.

Probably it's just me, but /var/ sounds to me like something always changing
but then again, I should check FHS (you don't know it by heart, do you? ;-))

> The OS and sysadmin distinction is there primarily to ensure that sysadmins 
> and OS/package defaults don't stomp on each other.  I'm not entirely sure if 
> this is needed, but it could be useful.

Yes, it is needed indeed.

> The order to load stuff could be:
> 
> 1) ~/.bash_completion
> 2) ~/.bash_completion.d/*
> 3) /etc/bash_completion.d/*
> 4) /var/lib/bash-completion/*

Maybe the other way round?
Remember that in bash, if you declare something already declared somewhere
else, you supercede that. So we really want the per-user configuration files to
supercede the global ones, so (also including my suggestion above to make
~/.bash_completion not contain any completion itself) the completions should be
read as:

1) /var/lib/bash-completion/*   # or whatever directory we choose
2) /etc/bash_completion.d/*     # backwards compatibility, and sysadmin-ground
3) ~/.bash_completion.d/*       # superceding completions in /var/lib/ and /etc/

> Then, have some kind of a blacklist mechanism (e.g. adding unwanted module 
> names to let's say a bash_completion_blacklist array) that each of the above 
> steps could use to prevent something from a later step from being loaded (and 
> obviously to add some additional things): users can blacklist sysadmin 
> (/etc/bash_completion.d) and OS (/var/lib/bash-completion) defaults, sysadmin 
> can blacklist OS ones.  It could obviously be done the other way around as 
> well, by letting users undef stuff that has been enabled by a previous step, 
> but that approach has the drawback that things a user may not want need to be 
> loaded anyway, only to be undefined a bit later.

Well, well... follow my idea:

~/.bash_completion and /etc/bash_completion: "configuration files", including
blacklisting (by the user / sysadmin). Those will obviously be needed earlier
than completions themselves. So the final sourcing cycle would be:

1) /etc/bash_completion         # read sysadmin's configuration, or provide
                                # distro-specific defaults here
2) ~/.bash_completion           # per-user configuration, shouldn't be touched
                                # by distro, overrides variables from /etc/
3) ### see above paragraph, the same steps go here.

This way, we source the configuration variables (including this
blacklist-thing) *before* actually sourcing any completion, thus fixing the
"bug" of loading completions that would be undefined/blacklisted by the
user/sysadmin at a later step.

Thoughts?

David

-- 
 . ''`.  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/9a088fcb/attachment.pgp