Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Case sensitive file names
Message-ID: <6036@ut-sally.UUCP>
Date: Fri, 17-Oct-86 19:09:37 EDT
Article-I.D.: ut-sally.6036
Posted: Fri Oct 17 19:09:37 1986
Date-Received: Sat, 18-Oct-86 00:30:44 EDT
References: <6002@ut-sally.UUCP> <5865@ut-sally.UUCP> <6018@ut-sally.UUCP> <6029@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 29
Approved: jsq@sally.utexas.edu

From: mordor!jdb@sally.utexas.edu (John Bruner)
Reply-To: jdb@s1-c.arpa 
Date: Fri, 17 Oct 86 14:39:08 PDT
Organization: S-1 Project, LLNL

It seems to me that there are three alternatives.  POSIX can specify
that conforming implementations must be case sensitive, must be case
insensitive, or may be either case sensitive or case insensitive.

If a conforming system must be case insensitive, then UNIX doesn't
conform.  If UNIX is to be included in the set of POSIX-compatible
systems, then case sensitivity must be permitted.

If a conforming system may be case sensitive or case insensitive,
then a lot of programs won't be portable.  Ignore for the moment
all existing UNIX code and consider new program development.  I
believe that programmers on one kind of system won't bother
with the library routines that are used to compare and/or convert
mixed-case names to monocase.  It doesn't matter what people "ought"
to do.  A well-known example of this effect is 4.2BSD.  The source
code is full of variables that should be declared "long" but --
since on the VAX "long" and "int" are identical -- are not.  In the
same way, optional case sensitivity will spawn code that only runs
correctly in the environment where it was written.

Therefore, I believe that case sensitivity must be retained, and
it should not be made optional.

Volume-Number: Volume 7, Number 68