From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] blanks in file names Message-ID: <20020702182329.D2941@cackle.proxima.alt.za> References: <20020702110848.F30EA19992@mail.cse.psu.edu> <003d01c221bf$0dfd9d30$6501a8c0@xpire> <3D21AAC0.D307E3AB@strakt.com> <3D21BF4E.9A3A6A39@gsyc.escet.urjc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <3D21BF4E.9A3A6A39@gsyc.escet.urjc.es>; from FJ Ballesteros on Tue, Jul 02, 2002 at 04:57:18PM +0200 Date: Tue, 2 Jul 2002 18:23:29 +0200 Topicbox-Message-UUID: bf99183e-eaca-11e9-9e20-41e7f4b1d025 On Tue, Jul 02, 2002 at 04:57:18PM +0200, FJ Ballesteros wrote: > > > > Some characters were just not meant to be in filenames, which would avoid the > > above. > > But they are, even in my system there're many files with blanks on their > names > (and I never choose such names). > I prefer the suggested option of an open(2) (openv?) that takes a strings vector instead of a slash-delimited path. It seems to me that such an approach is still viable as an objective and it would be expedient to keep it in mind and avoid developments that might defeat it. 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. Of course, I may be talking about a completely different operating system, but it strikes me that Plan 9 is the most suitable foundation for such a thing and its developers' abilities certainly (in my opinion) unmatched, so why not start there? ++L