[9fans] rc funny

[9fans] rc funny

[erik quanstrom]

	rb2; fn upas/fs {echo fu}
	rb2; upas/fs
	rc: can't open /env/fn#upas/fs: '/env/fn#upas' file does not exist
	fu

d'oh.  that's wierd.

- erik

Re: [9fans] rc funny

[lucio]

> d'oh.  that's wierd.

Is it?  You cannot have slashes in filenames, no matter what (that's a
decision Plan B should lift by representing, as I believe Rob Pike
recommended, paths as arrays of strings rather than slash delimited
strings).

So what do you expect when fuction names are recorded as filenames in
the environment?

++L

PS: would it not be even more consistent to use the 'x' bits instead
of the 'fn#' prefix to specify which entries in /env are executable?

Re: [9fans] rc funny

[Francisco J Ballesteros]

Probably it was a typo and you meant Plan 9, not Plan B. But anyway,
neither Plan B nor the octopus permit / in file names. Most scripts
handling file
names would break.
There was an old discussion about accepting ' ' in file names in this
list. I think
the same applies, even stronger, here.

On 4/1/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> > d'oh.  that's wierd.
>
> Is it?  You cannot have slashes in filenames, no matter what (that's a
> decision Plan B should lift by representing, as I believe Rob Pike
> recommended, paths as arrays of strings rather than slash delimited
> strings).
>
> So what do you expect when fuction names are recorded as filenames in
> the environment?
>
> ++L
>
> PS: would it not be even more consistent to use the 'x' bits instead
> of the 'fn#' prefix to specify which entries in /env are executable?
>
>
>

Re: [9fans] rc funny

[lucio]

> Probably it was a typo and you meant Plan 9, not Plan B.

No, I assumed that Plan B would have a bit more elbow room to be
creative in this instance, I'm not sure why I thought so.  I think, of
all "failures of vision", the slash in the path name was the worst
(and by no means as serious as some of the bloopers in other operating
systems).  One can live with it, but once it's pointed out to you that
it is not "the one and only way", it starts being a thorn in one's
side.

++L

PS: Mind you, you still need a convenient external representation and
that will put its own twist on it.  But one can live with the extra
freedom :-)

Re: [9fans] rc funny

[erik quanstrom]

> Is it?  You cannot have slashes in filenames, no matter what (that's a
> decision Plan B should lift by representing, as I believe Rob Pike
> recommended, paths as arrays of strings rather than slash delimited
> strings).

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

(there's a bug as / and '' would both be encoded as \0\0. i think this is
a fundamental problem because \0 is overloaded as the path seperator
and the end-of-string marker.)

when passed in to a program as argv[n].  such an encoding would
be required to preserve compatablity between other strings and
paths.

how would you expect to type a path at the shell prompt?

even if you turn this into an array of char* inside a program,
strings would now not be type-compatable with paths.  

do you have a reference for rob suggesting this?

- erik

Re: [9fans] rc funny

[lucio]

> 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