From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Subject: Re: [9fans] blanks in file names In-reply-to: from To: 9fans@cse.psu.edu Message-id: <200207082018.g68KIRo20092@dave2.dave.tj> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Date: Mon, 8 Jul 2002 16:18:27 -0400 Topicbox-Message-UUID: c5ae1580-eaca-11e9-9e20-41e7f4b1d025 Reply inline: - Dave Fco.J.Ballesteros wrote: > > I think we've lost focus. I'm scared. > > The whole point was to handle characters which are allowed but may > cause problems like ' ' and ''''. And AFAIK, the problem was that we > get them from outside systems, and that people may be so used to them > that they may even start to use them on native Plan 9 files. The reason that UNIX is so good and continues to be successful even competing against the biggest software company in the world is that UNIX has never taken this approach to solving problems; UNIX solves problems in a fundamental way, and Plan 9 must, too, if it's to be a worthy successor to UNIX. AFAIK, changing open(2), execve(2), etc. is a requirement if we want a fundamental solution to the problem. IMHO, the kernel should have an even more fundamental solution (seperation of the path into nodes, each of which is identified by a structure), while applications (which require a plaintext representation of a path) will probably want to escape special characters (by whichever method they want - since the kernel needs no escaping within itself, apps are free to do whatever they want). > > Don't you think that changing open, considering '/' in names, and > similar stuff is just too much? I'm scared. That may be interesting, > but it would lead to a very different system. It won't lead to a very different system from the application programmer's point of view. It'll lead to a different system under the hood, which is exactly what we want, because what we currently have under the hood simply doesn't cut it. > > Moreover, do you think that the system designers would ever consider > '/' as a legitimate character within file names? Although I don't > know, I'd bet they'll never do that (at least I have to say I would > never do it, sorry). There's no reason not to allow the slash in node names, except that it confuses utilities. However, whitespace already confuses utilities in the same way, so we lose nothing by allowing slashes in node names. > > I think I'm just going to try option bⁱ myself and then send a diff > in case it works out. Option b is a userland option, not a kernel option. All you're doing is deferring the decision to change our kernel until a later time (by which point we'll hopefully have a clearer idea about how we want to change the kernel). > > But above all, I will undo the changes made in this respect to my > local system if you guys or the system designers choose a different way. > It's a very nice system and I wouldn't like to get N different ones > nor to break it. Undoing kernel-level changes won't be easy, especially when people start coding programs using the kernel's new path representation; rewriting them using standard strings would (a) make the programs' logic a lot more complicated; and consequentally (b) make the programs a lot less efficient. > > > -- > ⁱ Option b was: remove quoting from ls et al, add it to those that > print commands, and fix those that don't cosider ' ' in file names. >