Using alias to commands disables its completion
Gustavo Serra Scalet
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux guttp 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44
UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.1
Patch Level: 7
Release Status: release
Description:
When an alias is supplied to a command (e.g: alias c="cd") the
complete doesn't complete like it used when using the original text,
without
using alias (e.g $ c <TAB><TAB> # returns all files, not just
directories)
It doesn't seem to have any technical issue problem to make the
detection of
completion also by using alias (as when <ENTER> is hit the alias are
also
interpreted).
Repeat-By:
$ alias c="cd"
$ c <TAB><TAB>
# suppose to only show directories, but it shows every file
Eric Blake
> Description:
> When an alias is supplied to a command (e.g: alias c="cd") the
> complete doesn't complete like it used when using the original text,
> without
> using alias (e.g $ c <TAB><TAB> # returns all files, not just
> directories)
>
> It doesn't seem to have any technical issue problem to make the
> detection of
> completion also by using alias (as when <ENTER> is hit the alias are
> also
> interpreted).
The lame answer:
But you can already do this yourself! Write a shell function around
alias, that calls both 'command alias' to do the real work, as well as
'complete -p' on the first word of new expansion then 'complete ...' on
the new alias name, so that you copy any completion properties tied to
the old name over to the new name.
As long as you define your programmable completions before your aliases
as part of your ~/.bashrc startup sequence, then this works.
Even better, submit that as an enhancement request to the
bash-completion project to have bash-completion provide that wrapper
around alias provided automatically as part of starting up bash-completion.
The answer you sort of wanted:
Yes, it would be nice to patch to bash's completion routines to add an
opt-in ability to check for programmed completion associated with
whatever the alias expanded to, and use that when there is no completion
already associated with the aliased name. But someone has to write such
a patch.
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Gustavo Serra Scalet
so fast...
On 24 March 2011 16:54, Eric Blake <ebl...@redhat.com> wrote:
> The lame answer:
>
> But you can already do this yourself! Write a shell function around
> alias, that calls both 'command alias' to do the real work, as well as
> 'complete -p' on the first word of new expansion then 'complete ...' on
> the new alias name, so that you copy any completion properties tied to
> the old name over to the new name.
>
hum. I took a look at [1] and understood what you said.
Nice idea, but it doesn't work for some compound aliases (ok, I made this
up. But you'll get it):
http://pastebin.com/khyeFGUS
I got what it happend but I don't know how to solve it.
>
> As long as you define your programmable completions before your aliases
> as part of your ~/.bashrc startup sequence, then this works.
>
> Even better, submit that as an enhancement request to the
> bash-completion project to have bash-completion provide that wrapper
> around alias provided automatically as part of starting up bash-completion.
>
Ok, I'll analyze that betterly. I just got introduced to bash-completion.
Thanks for that.
>
> The answer you sort of wanted:
>
> Yes, it would be nice to patch to bash's completion routines to add an
> opt-in ability to check for programmed completion associated with
> whatever the alias expanded to, and use that when there is no completion
> already associated with the aliased name. But someone has to write such
> a patch. <http://libvirt.org>
>
That may also be interesting :-)
Have a nice week
references:
[1] http://www.debian-administration.org/articles/316