(Sorry, forgot to CC the ML.) On Sat, Oct 15, 2011 at 1:30 AM, Chet Ramey <chet.ra...@case.edu> wrote: > Thanks for the report. This looks like a problem, or an omission, with > the effects of the `-f' option to complete, since it works as expected > without using programmable completion or when using `-o default'. I > will take a look. >
Yes, with `shopt -u progcomp' it does work as expected, unsurprisingly; otherwise, `complete -o default ls' works, but `complete -o default -f ls' doesn't. With a double quote in place of the single quote, it behaves identically: complete -f ls touch 2 2\"2 ls 2\"<TAB> # ls 2 ls 2\\\"<TAB> # ls 2\"2 With a space in place of the single quote, it works: complete -f ls touch 3 3\ 3 ls 3\ <TAB> # ls 3\ 3 ls 3\\\ <TAB> # ls 3\ 3 but honestly I wouldn't expect the double-quoted form to work. I'm have no idea how exactly completion works internally, but here it seems to me bash (or readline) double-dequotes the original word. If so, and since it seems unnecessary (and counter-intuitive) to me, would you enlighten me why (and how) the second dequoting is done? Also, I noticed the _quote_readline_by_ref() function in bash_completion[1], which I believe deals with this sort of problems. It's really ugly IMHO, and probably prompts for some change in bash's behavior. [1] http://bash-completion.alioth.debian.org/ <rant> I really don't want to use bash_completion. For most part, what I really need is to complete and filter filenames according to the calling command, e.g. directories for `cd', media files for `mplayer'. I'd like to write simple `complete' rules for these in simple bash, not having to load a host of hacks for it to actually work. Sounds reasonable? </rant>
