Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!pacbell!att-ih!chinet!les From: les@chinet.UUCP (Leslie Mikesell) Newsgroups: comp.unix.wizards Subject: Re: Kernel Hacks & Weird Filenames Message-ID: <4911@chinet.UUCP> Date: 21 Apr 88 22:42:01 GMT References: <13041@brl-adm.ARPA> <4895@chinet.UUCP> <11153@mimsy.UUCP> Reply-To: les@chinet.UUCP (Leslie Mikesell) Organization: Chinet - Public Access Unix Lines: 36 In article <11153@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>it is pretty silly to allow non-printable characters in a filename. > >This statement can be true, but note that it makes two assumptions: >first, that the file names are to be printed; second, that there are >non-printable characters. Are these assumptions true? Let us take >them in reverse. > >First, `non-printable characters'. Well, there are certainly numerous >characters that cannot be printed on the terminal I am using at the >moment (namely my H19). But this is not precisely the same set as are >non-printable on other displays. One notable exception is a display How many terminals do anything reasonable with ESC in random places? > >Second: are file names to be printed? Certainly most are. But there >are some that are not---for instance, the lock files used by this very >network news system are formed by putting `L' in front of the message >ID of each article; to lock the quoted article inews creates the file Would you enjoy debugging the operation of said locks if displaying the filenames performed random cursor motions or cleared the screen before you could see them. How about when you print a listing of the files on a backup set and have a few hundred page-ejects imbedded? Or is this "feature" to be used as a form of security? >So should the Unix kernel make the (relatively) irrevocable decision >to disallow locally-non-printing characters? Maybe---but I doubt it. It just adds another reason to place some sort of silly user agent between the user and the system. Besides, this is something that should be standardized to whatever extent possible to avoid trouble with networked files systems. Les Mikesell