Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Temporarily change completion options

0 views
Skip to first unread message

Mika Fischer

unread,
Mar 17, 2008, 9:14:03 AM3/17/08
to bug-...@gnu.org
Hi,

I'm currently working on the bash-completion package for Debian/Ubuntu.

I'd like to know if it is possible to change the options of the
programable completion within the completion function.

An example would be to allow environment variables in place of
filenames. But if I set -o filenames, the $ will be escaped and if I
don't set it then other things like & won't be escaped.

Another example would be java completion. There the first argument
should be a class (foo.bar.class). But the further arguments should be
treated as filenames. Since bash does not see . as a path separator I
have to use -o nospace to make the first argument work but this is
inconvenient for the filename arguments.

It would be very convenient if the completion function could alter the
options based on its understanding of the current command line. Setting
the options globally for a command means that the same options apply to
all arguments, which is often very inconvenient.

If there is a way to do this, or a workaround for problems of this kind,
I'd be glad for any pointers!

Regards,
Mika


Chet Ramey

unread,
Mar 17, 2008, 7:21:59 PM3/17/08
to Mika Fischer, bug-...@gnu.org, chet....@case.edu
Mika Fischer wrote:
> Hi,
>
> I'm currently working on the bash-completion package for Debian/Ubuntu.
>
> I'd like to know if it is possible to change the options of the
> programable completion within the completion function.

Not currently. I'm thinking about a new builtin that would accept the
same set of -o options as complete/compgen (and probably +o to turn
them off, as with the `set' builtin). There's no reason to invent a
new set of special shell varaiables.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/


Mika Fischer

unread,
Mar 19, 2008, 7:09:37 AM3/19/08
to Chet Ramey, bug-...@gnu.org
* Chet Ramey <chet....@case.edu> [2008-03-18 00:22]:

>> I'd like to know if it is possible to change the options of the
>> programable completion within the completion function.
>
> Not currently. I'm thinking about a new builtin that would accept the
> same set of -o options as complete/compgen (and probably +o to turn
> them off, as with the `set' builtin).

Yes, something like this would be very useful for the programable
completion.

But in the meantime can you describe what exactly these options do?

My understanding is this:
nospace: No not append a space after a completion even if it's the only
one.
filenames: Quote shell meta-characters and append a / if the sole
completion is a directory
dirnames: Has no effect if the compspec generates no matches?

So probably at least filenames could be emulated by the completion
function, right?

Regards,
Mika


Freddy Vulto

unread,
Apr 12, 2008, 3:25:08 AM4/12/08
to
On Mar 18, 1:21 am, Chet Ramey <chet.ra...@case.edu> wrote:
> > I'd like to know if it is possible to change the options of the
> > programable completion within the completion function.
>
> Not currently. I'm thinking about a new builtin that would accept the
> same set of -o options as complete/compgen (and probably +o to turn
> them off, as with the `set' builtin). There's no reason to invent a
> new set of special shell varaiables.

I also would like to see this option added.
Also, some kind of `complete-not-found' handler [1] would be nice.

These two additions combined would make it possible to write a run-
time completion loader, which would circumvent the need to have all
260K completions installed and loaded in memory - as does the current
bash_completion package.

See also: http://fvue.nl/Bash_completion_split

Regards,
Freddy Vulto

[1] The `complete-not-found' handler could be modeled after the
`command-not-found' handler, which is a Debian/Ubuntu addition to
bash. See: http://packages.ubuntu.com/gutsy/command-not-found

0 new messages