From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8c75ad56989c77def4ecb7b1f7cdb273@caldo.demon.co.uk> To: 9fans@cse.psu.edu Subject: Re: [9fans] blanks in file names From: forsyth@caldo.demon.co.uk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-nprqlnpcdysfyahbmcmzrjjxhu" Date: Thu, 4 Jul 2002 07:34:25 +0100 Topicbox-Message-UUID: c12ab856-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-nprqlnpcdysfyahbmcmzrjjxhu Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit the advantage of pushing stuff like this back to the boundaries, the points at which Plan 9 interacts with other systems and formats (often using 9P), rather than building it into the heart of Plan 9, is that at least the Plan 9 system itself can have straightforward internal rules. at the boundaries you're bound to be aware that there are differences (in practice). for instance, you can create names via dossrv that Windows itself cannot access properly (left as an exercise for the reader), but aren't prohibited by the FAT32 specification, or indeed, documented accurately anywhere. it's only a little better with 9660srv. the problem rob alluded to, by analogy with NAT, should not arise within the Plan 9 system. for instance, if i have a file of file names, can i read it in and be sure to access those names? if space is _ and _ is `boo!' it's anyone's guess. it's more understandable if, when problems do arise, they appear only at the boundaries with other systems, where there are necessarily some differences (remembering of course that any given difference might or might not be strictly `necessary'). so far, it seems to me: if Plan 9 allows space directly in the storage names, then space should be the character in the name, the quoting approach seems the only one that works properly, and we have some work to do to work out all the interactions with shell scanning (oh dear!), and changing (i suspect) the input conventions of quite a few commands, but still, it's a finite task. the possible scale of that task--even understanding all the implications-- can i think be underestimated, which is why i snarl a bit at people who are incredibly glib about it [which rob is not]. otherwise, Plan 9 should prohibit space in its file names, as previously, and the user interface can use something like U+00A0 to provide the functionality that at least some humans seem to think is essential. (computers don't give a dam whether names have spaces or not.) at the boundaries with Windows or Mac or Unix that character can be mapped to and fro, but there is already mapping of various sorts taking place there. (Windows itself has trouble enough with its conventions; another little exercise: what is a file name separator under Windows and how do you use it?) to return to the file name list example, it's less surprising that Plan 9 can't take a list of file in Windows style and access them directly. that wouldn't work whether space were allowed or not. Plan 9 already does translate at the boundaries between UTF-8 and whatever the other system uses. the latter approach handles not just space but also some other characters such as `/' that turn up at the boundaries, but cannot be handled by Plan 9. again, some are glib about the need for it, and i snarl again. even so, pragmatically there's no need to use one technique for everything if space is regarded as utterly different from all other such characters. space could be used as itself within the system and we can map `/' as and when we find it. it's also worth noting that having consistent quoting conventions to allow spaces in space-separated input is probably worthwhile on its own, so not all the work in Plan A will vanish. don't quit that editor just yet. --upas-nprqlnpcdysfyahbmcmzrjjxhu Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-1.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk id 1025734390:10:07734:3; Wed, 03 Jul 2002 22:13:10 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net id aa1107220; 3 Jul 2002 22:12 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id EC27319995; Wed, 3 Jul 2002 18:12:07 -0400 (EDT) Delivered-To: 9fans@cse.psu.edu Received: from ar.aichi-u.ac.jp (ar.aichi-u.ac.jp [202.250.160.40]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id 15154199B7 for <9fans@cse.psu.edu>; Wed, 3 Jul 2002 18:11:18 -0400 (EDT) Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3ciscupdate v148.2.1) To: 9fans@cse.psu.edu Subject: Re: [9fans] blanks in file names References: <20020703135427.6DA4919991@mail.cse.psu.edu> <1603408.1025710829@GOLD> Message-Id: <20020703221118.15154199B7@mail.cse.psu.edu> Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu X-Reply-To: arisawa@aichi-u.ac.jp List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 4 Jul 2002 07:10:55 +0900 Hello, >You can't do that becaause if a file contains a genuine >underscore, the outgoing software will think it's a space. the outgoing software will also think it's a underscaore. Is this important? Some OSs already map 'Windows' to 'WINDOWS'. Kenji Arisawa --upas-nprqlnpcdysfyahbmcmzrjjxhu--