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@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
