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

[Raphaël]

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