Re: [9fans] blanks in file names

[Dave <dave@dave.tj>]

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.
>