Re: tab completion error

[Mike Jonkmans]

On Mon, Sep 25, 2023 at 03:44:15PM -0400, Chet Ramey wrote:
> On 9/25/23 12:16 PM, Mike Jonkmans wrote:
> > On Mon, Sep 25, 2023 at 11:11:04AM -0400, Brian Vargo wrote:
> > > This is going to be very hard to explain over email.  I tried to use 
> > > script
> > > from util-linux in GNU bash v.5.1.16 on Ubuntu 22.04, but that doesn't 
> > > seem
> > > to offer any help.
> > 
> > A smaller reproducer:
> > 
> > mkdir empty
> > cd empty
> > mkdir a\ b
> > touch a\ b/f\ 1
> > touch a\ b/f\ 2
> > 
> > ls "a b"/"f<TAB>
> 
> OK. I still can't reproduce it, but it may be due to the fact that readline
> completes unclosed quoted strings as individual words. This means that the
> word actually being completed in the above case there is "f", not "a b/f".

If I manually add the missing quote at the end (before <TAB>),
then completion works correctly.

So perhaps the completion code could detect an unclosed quote
and then add one at the end, before doing the completion?

> The default bash completion doesn't give produce any completions for this,
> which implies that this is actually the work of bash-completion.

That is right.

Now without bash-completion (Ubuntu 22.04; bash 5.1):
ls a\ b/"<TAB>
Gives:
ls a\ b/"a b"/

Is also a (minor) issue.

> > ls "a b"/"a b/f # ends in space (correct)
> > 
> > The directory part is doubled.
> 
> And that might be why. bash-completion takes the word it thinks is being
> completed ("a b/f"), not the one readline is telling it is being completed
> ("f") and does the right thing with it. Unfortunately, since the word being
> completed is "f", that's what gets replaced with the new completion text.
> 
> It's sometimes easier to not put in the quotes yourself and let readline
> completion quoting add them.

That's how users should work around it.

Do we need to file an issue with bash-completion?

-- 
Regards, Mike Jonkmans