[Bash-completion-devel] Namespace

Ville Skyttä ville.skytta at iki.fi
Tue May 3 18:51:19 UTC 2011

On 05/03/2011 05:20 PM, David Paleino wrote:

> bashcomp_*?

The problem with functions starting with a letter is that it'll pollute
the list of available commands in a way that users are quite likely to
run into.  I don't think we want to have all our functions thrashing the
list of completions when someone does a

$ b<TAB>

> _bc_*?

This is the most obvious and least intrusive/annoying choice IMO.  For
functions we could use something more funky than just underscores and
letters, for example to start them with a colon, but for variables there
aren't that many choices.

But let's take a step back and establish the scope of all this, maybe
it's kind of clear but it doesn't hurt write and discuss/confirm it: my
opinion is that we should apply a namespace prefix to all our functions
and non-local variables.

For variables, there are two things: 1) internal ones such as the
current $_backup_glob and various similar per-completion ones, and 2)
ones controlling behaviour such as the ones documented in

For functions and internal variables we could use the same prefix (for
example _bc_*).  But for the "external" variables I think different
conventions should apply.  The current COMP_* is not optimal IMO because
it's possible that they'll clash with bash's own COMP_*, so I suggest
BASHCOMP_* for them.

And one important thing we should be planning for is considering what is
the bash-completion "API", i.e. what external completion authors can use
if they like and we'll try to keep that stuff stable, and what are
private things not intended to be used outside bash-completion proper
and which may change/disappear pretty much anytime.  I think these
deserve different namespaces, for example __bc_* or for the private ones
and _bc_* for the API ones, or something that makes the difference even
more visible such as _BC_* for the API ones.  (All functions that are
used as actual top level completion functions for commands would
probably be private.)

Agreed/disagreed/other considerations?

More information about the Bash-completion-devel mailing list