Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: case sensitivity
Message-ID: <6104@ut-sally.UUCP>
Date: Sat, 25-Oct-86 22:34:02 EST
Article-I.D.: ut-sally.6104
Posted: Sat Oct 25 22:34:02 1986
Date-Received: Sun, 26-Oct-86 04:38:19 EST
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 48
Approved: jsq@sally.utexas.edu

From: seismo!bellcore!jgs (Jeff Smits)
Date: Tue, 21 Oct 86 16:32:57 edt

One of the nice things about the UNIX system, is that the operating system
doesn't try to define precise semantics of the  use of its facilities.
"A path-name is a null-terminated character string starting with an optional
slash (/), followed by zero or more directory names separated by slashes,
optional followed by a file-name." (From the System III reference manual)
That is all the semantics attached to the concept of a path-name.

By leaving the semantics simple, it makes it easy to support file/path-names
with international characters in them.  UNIX Pacific offers a source product
called JAE 1.0 (Japanese Application Environment) based on System V, Release
2.1.0.  Included in its features is support for Japanese file-names as
documented in the Future Directions section of SVID Issue 2.
The basic concept is that the US ASCII code-set is always present contained
in the code-set range 001-0177(octal).  The range above 0177 (0x200-0x377 on
an eight-bit machine) is reserved for international characters.  No changes
were needed to the core operating system to support this.  Many of the utilities
function correctly with these code-sets.  This is all because there were no
additional semantics attached to the meaning of a character in a path-name.

It is the terminal driver's responsibility to convert the data received from
an international terminal into this internal representation.

The important point is that the operating system has no knowledge of the
code-set the path-names are written in.  The only assumption made about a
path-name is that the '/' character separates components in a path, and
the NULL character terminates the path.

If the standard changed to support case translation, it would be building an
code-set bias into an operating system implementation.  It would be difficult
to support the variety of code-sets with that type of conversion being done
in the operating system.

Due to international considerations and the fact that current practice
(both System V and BSD) support case sensitive file-names, I think
the current P1003 draft is correct with respect to case sensitivity.


						Jeff Smits
						AT&T Information Systems
						..!attunix!jgs
						(201)-522-6263
						190 River Rd.
						Summit, NJ 07901

Volume-Number: Volume 7, Number 86