On Sat, Oct 15, 2011 at 1:30 AM, Chet Ramey <chet.ra...@case.edu> wrote:
> On 10/13/11 10:37 AM, lolilolicon wrote:
>> Inside an empty directory:
>>
>> touch 1 1\'1
>> complete -r ls
>> ls 1\'<TAB> # ls 1\'1
>> complete -f ls
>> ls 1\'<TAB> # ls 1
>> ls 1\\\'<TAB> # ls 1\'1
>>
>> (Note: the comment on the right is the result after pressing <TAB>)
>>
>> Is this broken behavior?
>> Why on earth does the user have to double-escape at all?
>> Is there any benefit of this?
>
> Thanks for the report. This looks like a problem, or an omission, with
> the effects of the `-f' option to complete, since it works as expected
> without using programmable completion or when using `-o default'. I
> will take a look.
>
OK, some more strange test results.
In the interactive bash shell, I did this (in an empty directory):
$ mkdir 1\'1 $ mkdir 2@2
$ touch 1\'1/one $ touch 2@2/two
$ compgen -f "1'1" $ compgen -f "2@2"
1'1 2@2
$ compgen -f "1\'1" $ compgen -f "2\@2"
$ compgen -f "1'1/" $ compgen -f "2@2/"
2@2/two
$ compgen -f "1\'1/" $ compgen -f "2\@2/"
1\'1/one 2\@2/two
(Note: Put side by side for comparision.)
A bit inconsistency here. Then I wrote a bash script to do the same thing,
#!/bin/bash
shopt -s progcomp
mkdir -p 1\'1 2@2
touch 1\'1/one 2@2/two
for i in \
"1'1" "1\'1" "1'1/" "1\'1/" \
"2@2" "2\@2" "2@2/" "2\@2/"; do
printf -- '%5s => %s\n' "$i" "$(compgen -f "$i")"
done
# (Same results using `compgen -o default')
yet with different results:
1'1 => 1'1
1\'1 =>
1'1/ => 1'1/one
1\'1/ =>
2@2 => 2@2
2\@2 =>
2@2/ => 2@2/two
2\@2/ =>
What's going on with all this inconsistency?
Also, dumb question, but is `compgen' supposed to accept quoted arguments or
dequoted ones? e.g., "1\'1/" or "1'1/"?
Thanks
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
>
