[Bash-completion-devel] Some advise for bash-completion/bash_completion

[Peter Dave Hello]

Hello,
Thanks for Raphael's answer,  so ... maybe my bash-completion's version in
my Debian GNU/Linux is too old,  I will update it by myself and  try it
again, thanks again :)
Regards,
Peter


2014-02-11 20:16 GMT+08:00 Raphaël <raphael.droz at gmail.com>:

> On Wed, Feb 05, 2014 at 12:06:08PM +0800, Dave Hello wrote:
> > I wanna ask to remove_expand() function in bash_completion, because bash
> > already have the function (ref:
> >
> http://www.gnu.org/software/bash/manual/html_node/Readline-Init-File-Syntax.html#Readline-Init-File-Syntax
> ),
> > just set  expand-tilde on and it will works fine,
>
>
> I don't see such a remove_expand() function in bash-completion (git master)
>
> There is a  __expand_tilde_by_ref which is used by:
> - mutt, to check config files exist (not sure it's the expansion is
>   needed here)
>   (
> https://alioth.debian.org/tracker/index.php?func=detail&aid=312759&group_id=100114&atid=413095
> )
>
> - _known_hosts_real(), which extracts ssh *hosts* directives, then check
>   these files (can't tell why it's needed here).
>
>
> Secondly, there is an _expand() function which is heavily used.
> (namely: bzip2 dd dpkg find gcc gzip info lrzip lz4 lzma lzop man mutt
> povray rsync ssh sshfs umount.linux xz zopfli)
>
>
> There, the comment state:
> > # Expand ~username type directory specifications.  We want to expand
> > # ~foo/... to /home/foo/... to avoid problems when $cur starting with
> > # a tilde is fed to commands and ending up quoted instead of expanded.
>
>
> My guess is that the benefit of this function is to expand arguments
> when compopt -o filenames is *not* used because readline expansion
> *only* applies to the built-in filename completion.
>
>
> The code in its current state is consistent with the facts :
> $ ls ~/<TAB>
> # is *not* expanded
>
> $ find ~/<TAB>
> # is expanded
>
> $ bind 'set expand-tilde on';
> $ notexist ~/<TAB>
> # is expanded
>
> $ bind 'set expand-tilde off';
> $ notexist ~/<TAB>
> # is *not* expanded
>
> but it does not explain the reason for this inconsistency between `ls` and
> `find`.
>
> See also:
>
> http://superuser.com/questions/442765/why-does-bash-tab-expand-a-tilde-when-i-am-completing-a-vim-file-name
>
> So the question could be:
> > "why expand continues if I disabled expand-tilde" ... "when it's
> > apparently not useful for the completion process itself ?"
>
> I don't have the answer, but see:
>
> http://www.linuxquestions.org/questions/linux-software-2/how-to-stop-bash-from-replacing-~-with-home-username-643162/
> then:
> https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/622403
> which is outdated since the `_rl_enabled expand-tilde` check is not used
> in __expand_tilde_by_ref() anymore.
>
> At some point the whole expansion mechanism was disabled:
>
> https://alioth.debian.org/tracker/index.php?func=detail&aid=311431&group_id=100114&atid=413095
> (side note: why isn't the tracker public anymore ?!)
> ... then re-enabled.
>
> Last thing, according to fdb080ff8 commit message, it seems that using
> _tilde() rather than _expand() respects the expand-tilde setting for
> filenames. _filedir() which relies on it prove that:
> The  $1 != */* in _tilde exclude tilde-expansion in paths (ccbf141e). I
> don't know
> if it was the "right-way" to avoid abusive tilde-expansions as it was
> to be the objective according to the commit message.
> More of this _expand || return date back from 2010 (and sometimes far
> further), before _tilde() existed, this may be a simple explanation.
>
>
>
> In the end I join myself to your question, stated in a different fashion:
> Why the `find` completion relies on _expand || return 0 when most
> others, while providing a filename completion too, do not. (eg: `cd`) ?
>
>
> regards
>
>
> --
> GPG id: 0xD7F62B21
>
> _______________________________________________
> Bash-completion-devel mailing list
> Bash-completion-devel at lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20140211/d5b159e1/attachment.html>