[9fans] rc funny - Plan9

This is a discussion on [9fans] rc funny - Plan9 ; 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...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [9fans] rc funny

  1. [9fans] rc funny

    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

  2. Re: [9fans] rc funny

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


  3. Re: [9fans] rc funny

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


  4. Re: [9fans] rc funny

    > 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 :-)


  5. Re: [9fans] rc funny

    > 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

  6. Re: [9fans] rc funny

    > 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


+ Reply to Thread