* Chet Ramey <[EMAIL PROTECTED]> [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
