> this is not a serious limitation. your suggestion to use an array of char*
> would be equivalent to saying use \0 as the path delimiter. now paths are
> not compatable with other strings used by the c library. as i understand
> your suggestion, you would encode /env/fn#upas/fs as
>
> \0env\0fn#upas\0fs\0\0
Not at all. For use externally, any path separator would do, it would
be a matter of choice by some agency, typically the shell. To give a
silly example, generations of MS-DOS and Windows translated the
backslash to a forward slash for use by the kernel. I'm not sure
exactly where the translation occurred, I think it was within the DOS
calls, in a preamble.
As I understood Rob Pike's suggestion, the few Plan 9 operations that
involved walking the directory structure would need altering to use
string arrays instead of slash separated components. I recall that it
was proposed in the addition of a multi-component walk in 9P2000.
Assuming that I can walk to (env 'fn#upas/fs'), it is a matter of
external representation to get that to 9P. in 'rc' it may be possible
to have SLASH='\'; upas/fs; SLASH-'/' as an unimaginative possibility.
Another option may be to use shell tuples as paths: ls -l ('' sys src
cmd).
To extrapolate this to intentionally make life a misery for the user
as your example does, would be a bit extreme. I do accept that the
additional complexity is hardly worth the change, but on a
philosophical level treating slash as potentially the same as any
other filename character makes a lot of sense.
++L
