On Thu, Oct 31, 2024 at 05:31:17AM +0100, Lionel Élie Mamane wrote: > $ rm * > $ touch 'a:b' 'a:c' > $ ls <TAB> > # gives > $ ls a\: > # this is escaped even though it strictly didn't have to be > # but that is not incorrect, acceptable > # again, different from what happens with "$" > # delete the command line, and start a new one: > $ ls a:<TAB> > # nothing happens, OK, there are two matches,
correction, not "nothing" but the command line becomes $ ls a:a\: > $ ls a:<TAB><TAB> > # no match! this is NOT correct. There are two matches, > # a:b and a:c again, correction as above Maybe this example will be more striking: $ dpkg -l bash | grep bash ii bash 5.2.32-1+b2 amd64 GNU Bourne Again SHell $ echo $BASH_VERSION 5.2.32(1)-release $ complete -p # no output, bash-completion installed but not enabled $ rm * && touch 'a$b' 'a\$c' $ ls a$<TAB> # result: $ ls a\$b # meaning it matched the filename a$b, but: $ ls a\$<TAB> # result: $ ls a\$b # meaning it did not match the filename a\$c if for filename completion "the text before point" should be taken as a raw string (as it was in the "a$<TAB>" case) then "a\$" should match with "a\$c". If for filename completion "the text before point" should be taken as a quoted string according to shell rules (as it was in the "a\$<TAB>" case) then "a$" should NOT match with any of these filenames. The behaviour is not uniform, not coherent.
