Re: Filename completion broken on single quote

[lolilolicon]

(Sorry, forgot to CC the ML.)

On Sat, Oct 15, 2011 at 1:30 AM, Chet Ramey <chet.ramey@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>