Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!ucbcad!nike!lll-crg!seismo!ut-sally!std-unix From: std-unix@ut-sally.UUCP (Guest Moderator, John B. Chambers) Newsgroups: mod.std.unix Subject: Re: Case sensitive file names Message-ID: <5921@ut-sally.UUCP> Date: Mon, 6-Oct-86 13:07:33 EDT Article-I.D.: ut-sally.5921 Posted: Mon Oct 6 13:07:33 1986 Date-Received: Mon, 6-Oct-86 23:18:38 EDT Organization: IEEE 1003 Portable Operating System for Computer Environments Committee Lines: 94 Approved: jbc@sally.utexas.edu Date: Mon, 6 Oct 86 09:56:50 edt From: philabs!nyit!rick@seismo.CSS.GOV Subject: Re: Case sensitive file names Regarding comments by Mark Crispin : > I would like to add a loud "Bravo!" to Mark Horton's message! The present > case sensitivity of the Unix filesystem is a real drag, and something that > has regularly and reliably caused me problems when working in a heterogenous > environment. What specifically is wrong with case-sensitivity? I work on both case-sensitive (UNIX) and other (TOPS-20) systems regularly, and have no problems in switching between them. > As far as I can tell, the only individuals who actually *like* > case sensitivity in Unix are the high-schoolish hackers who think it's really > cute to write programs with separate -1, -l, -I, and -L switches. And many software professionals. > I think that the most reasonable proposal is to do a free case match on input, > so that "more foobar" is the same as "More FooBar", etc. On output, you first > do a free case match to see if there is an extant file and if so preserve the > case of that file. In other words, if I overwrite FooBar but specify foobar > or FOOBAR, the file is still called FooBar. Otherwise, use whatever case the > user specifies. Renaming would always use the case the user specifies, so the > user can rename foobar to FooBar, etc. Changing the UNIX kernel to behave like this is, of course, within the capabilities of a single programmer. However, not all filename recognition under UNIX occurs in the kernel, and you're going to have an awesome task finding and rewriting all those user-mode programs that know implicitly that filenames are case-sensitive. The problem is exacerbated by the fact that you're going to a more complex scheme than what was there in the first place. > ... a FooBar.Txt file is possible on TOPS-20, but only by > F<^V>o<^V>oB<^V>a<^V>r.T<^V>x<^V>t. > For once, I don't favor the TOPS-20 way of doing things. TOPS-20's scheme is > alright if you started with case independence to begin with, but I don't think > it would fit in well into Unix, and certainly not without a major flag day. I > hope that my suggestion above could fit in with only minimal inconvenience. It could fit in *part of the way* with minimal inconvenience. > I found on TOPS-20 that no serious user used case-sensitive filenames. You've got the cart before the horse. No serious TOPS-20 users used case-sensitive filenames because of the inconvenience in entering filenames with embedded lowercase characters. On output, filenames with embedded ^V characters are aesthetically unpleasant as well. > Everybody > appreciated the case-insensitivity of the interface, even though it took the form > of coercing to upper case. You can replace the word "appreciated" with the words "became accustomed to". Also, this argument fails on the grounds that it's hard to get people to vote rationally on a subject that involves a decision to change from something they're comfortable with. > My experience also suggests that case sensitivity is > a pain in the a**; I tried writing a major utility in Interlisp using mixed case > function and variable names and eventually gave up when most of my errors turned > out to be case errors. How about keeping all variable names in one case? > It's *so* much easier to keep the shift lock key down... > > -- Mark -- It's just as easy to leave the shift lock key up. Many typists do. The issue of case-sensitivity is a subjective one, thus you'll always find many vehement proponents on both sides of the fence. At this point in the development of UNIX, such a fundamental change in the behavior of the OS would receive at best only partial acceptance among the myriad UNIX implementations, leading to even more divergence. This effect diametrically opposes the purpose of a standard. ----- Rick Ace Computer Graphics Laboratory New York Institute of Technology Old Westbury, NY 11568 (516) 686-7644 {decvax,seismo}!philabs!nyit!rick Volume-Number: Volume 7, Number 25