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

23 May 1997 15:39:45 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [email-masked]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Original-To: "[email-masked]" <[email-masked]>
Original-Sender: [email-masked]

At 11:08 AM 5/22/97 -0400, Michael Condict wrote:
>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.

Being fairly new to this group I have a question.  Is it expected that
changes like this will get folded back into the main source distribution or
do they remain idividual efforts?  Will you have to apply the same patches
on the next release etc.?  How are decisions like this made?  Is it simply
a consensus and then cygnus takes the best ideas/suggestions and then
merges them in when they get the opportunity?

>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 like it - now to change my aliases :-)

>> 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.

True, also as you said, if there are two possible matches differentiated by
case then it should go for the case matching one first.  That'll cut down
on the number of times that the option will need to be toggled.

Thanks for the follow up - Guy

-- 
Guy Gascoigne - Piggford ([email-masked])
Software Engineer, Informix Software, Inc. (Portland, Oregon)
(503) 225-4574,  Fax (503) 221-2633

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".