delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/01/02/07:10:19

From: blake AT edge DOT net (Blake McBride)
Subject: RE: Observations and suggestions
2 Jan 1997 07:10:19 -0800 :
Sender: daemon AT cygnus DOT com
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <199701021247.GAA11651.cygnus.gnu-win32@edge.edge.net>
Mime-Version: 1.0
X-Sender: blake AT edge DOT net
X-Mailer: Windows Eudora Version 2.1.1
Original-To: gnu-win32 AT cygnus DOT com
Original-Sender: owner-gnu-win32 AT cygnus DOT com

At 05:32 PM 1/1/97 -0500, Fran Litterio <flitterio AT amulet DOT com> wrote:
>Blake McBride (blake AT edge DOT net) writes:
>
>>Unfortunately, the NT OS does not distinguish between file name case
>...
>>I therefore recommend that we default to ignoring case
>>and allow case differentiation be again setting an environment variable
>>or 'set' option.
>
>An environment variable would be preferable to using the shell's set
>command.  More than one shell will eventually be ported to the cygwin32
>environment (zsh anyone?).
>
>>[...] it would probably be best if
>>'ls' would integrate case names as opposed to displaying files which
>>start in caps separate from those that start in lower case.
>
>The right way to implement this is in the low-level file-name
>manipulation routines (opendir(), readdir(), open(), creat(), etc.) in
>cygwin.dll.  The default behavior could be for those functions to
>downcase all filenames all the time.  The whole world will look like
>only lowercase filenames are allowed (even "touch FOO" will create a
>file named "foo"), and consistent behavior will ensue (for instance, you
>would type "ls *.c" instead of "ls *.c *.C" to see all C source files).

I definitely don't agree with this approach although it would be very
simple to implement.  Not recognizing a difference between file name case
when opening a file is bad enough but not as bad as not allowing any upper case
at all!  Arguably, there are some good reasons to deal with file names as
Microsoft chose to, especially when dealing with end-users who are confused
as it is without telling them that 'a' and 'A' are different.

I still say we should:

1.  Create and display files with the specified case

2.  Integrating the case during display (ls) as apposed to displaying
    uppercase names and then lower case names)

3.  Wildcard match and open files without regard to case

4.  Support a special optional mixed case support ala ^M^akefile
    for unix porting

IMO, any other approach will only cause conflict and hassle between the
tools and the forced operation of NT.  Remember, I don't approve of the
way NT works.  It's simply a fact.  I don't want to snub my nose at NT's
method by not supporting it only to cause endless hassles on myself
which simple reduce the tool's appeal.

>
>Yes, a small minority of tools want to manipulate files such as
>"makefile" and "Makefile" at the same time _and_ have them be different
>files.  To allow those tools to compile without changes, has anyone
>considered doing something similar to the Win95 long-filename-trick: map
>mixed-case filenames to a mangled form (e.g., "Makefile" is stored in
>disk as "^M^akefile") and a hidden file in the same directory stores the
>mapping from mangled to demangled name ("^M^akefile" -> "Makefile").  If
>a process has the magic environment variable set, the cygwin.dll file
>manipulation functions would test for the existance of the mapping file,
>and bingo -- mixed-case filenames in a single-case file-system.  Of
>course, those mangled names would be visible to any non-cygwin32
>appliaton, but that's no different than the current mixed case solution
>(and probably is completely unavoidable).

Although I find the current mixed mode appealing I think (in my case) it
has limited value since I find it hard to deal with files that can only
be referenced by cygwin.dll applications.  If that was the case I might
as well just use Linux (which I really love).


>
>Comments?
>
>>BTW, the mixed case mode of mount doesn't work on NT 4.0.  I think this
>>may be due to NT 4.0 not allowing ^ in a file name.
>
>NT 4.0 workstation does allow that character in a filename.  I just
>tried it: touch 'foo^bar'.


I can't speak for your 'touch' but I can tell you two things about NT 4.0.

1.  copy con foo^bar       doesn't create with the ^

2.  Unless I'm doing something wrong, mixed case mode with 17.1 and NT 4.0
    does not work.

Please show me where I am in error.

--blake


--
Get info on my Dynace Object Oriented Extension to C
and Windows Development System from:
http://www.edge.net/algorithms
Blake McBride (blake AT edge DOT net)
Algorithms Corporation - 615-791-1636 - USA

-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019