Path: utzoo!yunexus!geac!daveb
From: daveb@geac.UUCP (David Collier-Brown)
Newsgroups: comp.unix.wizards
Subject: Re: FileNames with the high bit set.
Summary: Artifact, perhaps?
Message-ID: <2558@geac.UUCP>
Date: 11 Apr 88 12:45:57 GMT
Article-I.D.: geac.2558
Posted: Mon Apr 11 08:45:57 1988
References: <8120010@eecs.nwu.edu>
Reply-To: daveb@geac.UUCP (David Collier-Brown)
Organization: /usr/lib/news/organisation
Lines: 21

In article <8120010@eecs.nwu.edu> naim@eecs.nwu.edu (Naim Abdullah) writes:
| On our 4.3+NFS (Mt. Xinu) system on a Vax780 and also on a Sun 3/60
| running SunOS 3.5, open(2) and creat(2) return EINVAL if the pathname
| supplied to them has a character with the high order bit set.
| 
| Why is this ? Has this behaviour been added by Berkeley Unix or has
| it "always" been there in Unix ? Is it because sh(1) uses the parity
| bit for it's own purposes and the kernel does not want to create
| files that the shell might not be able to handle in this manner ?
| (or is it, that sh(1) knows about this kernel idiosychracy and exploits
| this behaviour for it's own advantage..).

  I suspect its an accident, and know it can be removed: we're using
a "8-bit clean" environment here, with the exception of vi. Neither
the shell(s) nor the kernel cares any more.  Various programs have
problems, though...
-- 
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind) 
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.