if I type in a path:
(1st example)
> ls -d /share/doc/new<tab>, bash displays:
ls /share/doc/New\ Folder
Pressing 'Enter' gets:
ls: cannot access /share/doc/New Folder: No such file or directory
vs.
(2nd example)
> ls /share/do<tab>
ls /share/Doc/n<tab>
ls /share/Doc/New\ Folder/ (<enter>)
/share/Doc/New Folder//
-----
The first case did a path lookup in case-insensitive manner, and only
corrected case for the last path element -- but it needed to correct
the case for the 2nd element in order for the 3rd element to be 'valid'...
So it needs to case-correct all needed path elements that it used to
generate the completion it displays (otherwise it appears to give a
completion in an invalid pathname).
and 2nd item -- I suspect it is related to the first item --
it doesn't append "/" in the 1st example because it tries to look
up "New Folder" under the displayed path and fails -- BUT,
I think it very well might be correct behavior IF:
a) it is supposed to display the longest common string,
and then
b) present a menu for options.
Since the "ls" command can terminate after the "New Folder" (i.e. the
"/" would be part of a different command (looking up "New Folder/"
which makes a difference in some 'copy' commands).
In any event, correct or not, the 2nd example appends the "/"
and ends up yielding a "//" in ls (or a different target in some
copy commands). So which ever is "correct"**, it should do the same
completion in both cases.
**-- controlled by inputrc, I believe -- I have (relevant settings):
set mark-directories on
set meta-flag on
set output-meta on
set menu-complete-display-prefix on
set print-completions-horizontally off
set show-all-if-unmodified on
set show-all-if-ambiguous off
