From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6b76d268c7227b6451a9cd533b0576a7@plan9.escet.urjc.es> To: 9fans@cse.psu.edu Subject: Re: [9fans] blanks in file names From: Fco.J.Ballesteros MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Wed, 3 Jul 2002 10:00:55 +0200 Topicbox-Message-UUID: bfbbb06a-eaca-11e9-9e20-41e7f4b1d025 rog@vitanuova.com : : /sys/src/cmd/dossrv : /sys/src/cmd/9660srv : /sys/src/cmd/tapefs : /sys/src/cmd/unix/u9fs : /sys/src/cmd/ftpfs : convert "space char" to/from external actual space on create, : walk, wstat, stat and directory reads. One crazy idea I had was to do that translation in the mount driver. That way the server would be happy to think that it uses space, and the client plan 9 program would be happy to see 00A0 or whatever without confussion with the space character. lucio@proxima.alt.za : : What I'm saying, is that I'd like to target a kernel that is entirely : delimiter agnostic and promote each user application in the same : direction as a long-term project. In the interim, constructs that : cast delimiters in stone should be removed wherever possible. IMHO, the problem is mostly the user programs and not the kernel. AFAIK, the kernel is fine if you don't use / and \0 as delimiters (which seems reasonable to me, although some guys might want to use it too). But the tradition that blanks separate arguments is deeply embedded in user programs, perhaps most notably the shell. Assume the kernel has changed to use openv[], what would the shell do to deal with spaces vs 00A0s ?