Subject: Re: Fix to readline for case-insensitive file-name completion
From: [email-masked] (Michael Condict)

23 May 1997 13:38:54 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
X-Authentication-Warning: postman.opengroup.org: Host hare.osf.org [130.105.7.99] didn't use HELO protocol
Original-To: Guy Gascoigne - Piggford <[email-masked]>
Original-cc: "[email-masked]" <[email-masked]>, [email-masked]
In-reply-to: Your message of "Wed, 21 May 1997 07:49:29 PDT."
             <[email-masked]> 
Original-Sender: [email-masked]

In message <[email-masked]>, you write:
> Well just to show that this discussion isn't completely one sided :-) I'd
> have to say that I'm quite in favour of case-insensitive file name completion.

Thanks, I was beginning to feel that I'm the only one who wants it.  I've
now modified the shell file globbing as well as the filename completion,
so they're both case insensitive.  It's really nice to be able to say:

		ls make*

and not worry about what case the file was stored in when you unzipped
it or ftp'd it or are accessing it via a distributed file server.
All of these ways of getting files tend to do unpredictable things to
the upper/lower case.

I also discovered a quaint fact about GNU ls and the layout of the NT
file system:  try "ls -U".  It causes ls not to sort files, but print
them in the order that they're stored in the directory.  Well it turns
out that NT file systems (but not DOS FAT file systems) are stored in
case-insensitive alphabetic order!  So "ls -U" prints the files in the
this order, which is exactly what I want.

I have some questions for those of you who like case sensitivity:  Do
you get irritated or confused by the index in the back of books, which
is printed in case-insensitive order?  Or how about when you look up
words in the dictionary?  Are "House" (at the beginning of a sentence)
and "house" (in the middle of a sentence) two different words?  I ask
this as a UNIX lover and systems programmer for more years than most of
you.  It's one of the few things that UNIX and C got wrong.

> Having moved to NT quite a while ago, I've got used to the case-ignorance
> of the file system and as I use the cygwin tools to enhance NT rather than
> simply mimic UNIX I have absolutely no problem if there are features here
> that are only really going to be of interest under NT.

I concur on this.  I guess this is why you and I want case-insensitivity.
We are interested in using native NT (not covering it up with a complete
UNIX emulation layer) and merely want some better non-GUI tools for it,
like a decent find / grep and an intelligent shell that is more
user-friendly then the NT/95 command processor (which can't even handle
"cd //host/sharename/...")

> Perhaps this behaviour could be dependant upon the value of a shell
> variable or setting?

It looks like an environment variable is the way to go.  I admit that
when I tried out my changes on a networked UNIX file system, in which
I had two side-by-side directories named "jade" and "JADE", it was
suboptimal.  When I typed "cd ja<TAB>", my version of file completion
modified the name to "JADE" and beeped at me because there was more than
one matching name.  This is fine if it picks the right version of two
matching files, but it doesn't prefer to match the one that is in the
same case that you typed -- it just picks the first file that matches
what you typed so far, and modifies your case to that name.  So, while I
could fix this by making the code always try a case-sensitive match
first, then revert to case-insensitive only if nothing matches, if might
be better to be able to dynamically turn on case-sensitivity when
perusing particular file systems or directories.

Michael Condict			[email-masked]
The Open Group Research Inst.	(617) 621-7349
11 Cambridge Center
Cambridge, MA 02142
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".