Re: bug in 'rm' completion

[Bart Schaefer <schaefer@brasslantern.com>]

On Nov 9, 12:29am, Greg Klanderman wrote:
}
} Will look into fixing these at some point but figured I'd report them
} first in case the fix is obvious to anyone out there.. I assume both
} examples are manifestations of the same bug.

At first I thought this was a(nother) problem with _path_files but it
appears instead to be pretty plainly this in _rm:

case $state in
  (file)
    declare -a ignored
    ignored=(${line//(#m)[\[\]()\\*?#<>~\^]/\\$MATCH})
    _files -F ignored && ret=0
    ;;
esac

A _complete_debug trace shows:

+_rm:33> case file (file)
+_rm:35> declare -a ignored
+_rm:36> ignored=( foo ) 
+_rm:37> _files -F ignored

The most recent change was:

2009-08-17  Peter Stephenson  <p.w.stephenson@ntlworld.com>

        * 27219: Completion/Unix/Type/_files: "_files -F <array>" wasn't
        correctly handled, which broke duplicate filtering in _rm.

(BTW "wasn't" has a UTF-8 apostrophe in the actual ChangeLog file.)

So _rm is attempting to filter duplicates out of the completion list,
but ends up filtering out unambiguous prefixes as well.  Fixing one
bug exposed a different one.

The easy fix of swapping in

    { _files -F ignored || _files }

solves the foo{1,2,3} variant but not the foo{,-bar} variant because
the presence of foo-bar allows _files -F to succeed even though it
skips foo.  There may not be a way to satisfy all constraints here.