[Bash-completion-devel] New directory layout

[Ville Skyttä]

On Friday 16 January 2009, David Paleino wrote:
> On Thu, 15 Jan 2009 23:18:16 +0200, Ville Skyttä wrote:
> > 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.

Works for me.  Except "core", that looks too much like a program crash dump.

> > 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.

Works for me.  But people are of course free to add whatever they want to 
their ~/.bash_completion.

> > 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.

Works for me.

> >     /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.

I'll comment on this in a separate reply to Santiago's mail.

> 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.

I guess this is essentially the same as my original suggestion except that 
users could not preemptively use their ~/.bash_completion to prevent anything 
that happens in /etc/bash_completion.  Whether that's a problem depends on 
what /etc/bash_completion contains.

But then again, on a 2nd thought, I'm not quite sure that a mechanism for 
disabling complete completion modules is needed; the Mandriva approach of 
cherry-picking slow or otherwise problematic sections of some completions 
that users/sysadmins can configure to be skipped starts to make more and more 
sense to me.

By the way, it's not quite clear to me at which point the "base" completion 
module would be loaded in the above.  It'd be good to let users that don't 
want our stuff at all to opt out completely even if the stuff or a subset of 
it is installed and enabled in sysadmin configs.  I failed to note and take 
this into account in my original brain dump - in that I was thinking that 
the "base" module is the orchestrator that is responsible for loading other 
configs and modules.  So perhaps sourcing ~/.bash_completion 
and /etc/bash_completion should be moved to what's currently 
bash_completion.sh.

Ooh, this is getting hairy.  Writing a complete list of use cases we want to 
support and then working on based on that could be easier...