bash tab completion confused when one subcommand is a prefix of another

[dkg]

Make sure you completed the following tasks

• Searched the discussions
• Searched the closed issues

Code

Please see sequoia's sq for code. The problem i'm reporting is that sq key<TAB> does the wrong thing.

I reported this concern to sequoia and they indicated that it is a bug in clap's bash tab completion. I describe it in more detail below.

Steps to reproduce the issue

1. build and install sq from the sequoia-sq crate. sq has two subcommands with the unusual property that one is a prefix of another: key and keyring
2. in bash, run touch keyfoo
3. in bash, type sq k<TAB> and it fills in to sq key
4. now hit <TAB> again.

Version

• Rust: 1.48.0
• Clap: 2.33.3

Actual Behavior Summary

sq key<TAB> completes to sq keyfoo because of the local file named keyfoo.

Expected Behavior Summary

It should require sq key<TAB><TAB> to show a list of two possible subcommands, key and keyring

Additional context

I note that the problem might be deeper than just when one subcommand is a prefix of another, though the prefix situation makes it more evident.

For example, sq has another subcommand with no lexical overlap with other subcommands: packet.

If i touch packetfoo and then in bash type sq packet<TAB> (note the lack of trailing whitespace), I'd expect bash to insert a space (because the subcommand token is complete, so we should move on to generating the next token). Instead, it autocompletes to sq packetfoo .

This isn't likely to happen during normal usage because sq p<TAB> autocompletes to sq packet (note the trailing whitespace) and sq packet <TAB> (again, note the whitespace) actually does the right thing.

Debug output

sorry, i don't have debug output for this case.