Re: compgen gets confused when trying to complete ambiguous special char

[Mika Fischer]

* Chet Ramey <chet.ramey@case.edu> [2008-03-17 18:47]:
> For historical reasons, complete/compgen dequote the filename they're
> passed, removing backslash escapes and interpreting embedded quoted
> substrings.

Yes. I've run into this problem now several times while trying to fix
the bugs in bash_completion. As far as I can see it's impossible to do
the completion the same way as the built-in completion.

When my ${COMP_WORDS[COMP_CWORD]} is STORE\' and I have the following
files in $PWD:
STORE'N'GO
STORE\'N\'GO

Then I have a hard time getting this information to compgen. The only
way I can think of is to do the shell-quoting myself and then let
compgen strip it away again. This is obviously not very nice, certainly
error-prone and maybe even impossible. Do you agree?

> (One of the things bash should do when it does that is to be better
> about obeying the shell rules about backslash-escaped characters and
> double quotes, but that doesn't matter for this example

Can you elaborate on the differences in case they're the cause of other
strange behaviours?

> though that function has several problems.)

Are you referring to compgen or some function in bash_completion?

> One possible change is to inhibit filename dequoting when compgen
> isn't run via a readline keybinding, but I'm not sure how much of an
> effect it will have on the problem, which occurs when completing.  It
> will make the behavior when run on the command line closer to what the
> completion will do.  This is an easy change; contact me if you're
> interested in evaluating it.

Yes, that would be nice. I'm willing to test it.

Another possibility would be to provide means to do shell-quoting and
de-quoting from within bash. Or is this possible in a safe and resonably
easy way even now?

> (The problem with SIGINT is completely different.  Some library state
> needs to be reset on SIGINT.  That will be fixed in the next version.)

OK, great!

Regards,
 Mika