[9fans] several things - Plan9

This is a discussion on [9fans] several things - Plan9 ; Hello few questions: 1) Having a window with rc and pressing CTRL+d usually closes the window. However, from time to time it does not. Instead, I can see EOT (one character; diagonally) written after the prompt, the window stays, I ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: [9fans] several things

  1. [9fans] several things

    Hello

    few questions:

    1) Having a window with rc and pressing CTRL+d usually closes the window.
    However, from time to time it does not. Instead, I can see EOT (one
    character; diagonally) written after the prompt, the window stays, I can
    write anything into the window, but my commands are not executed. When does
    this happen?

    2) Reading pwd.c I can see 'char pathname[512]' at the beginning of the main
    function. Does it mean plan9 paths are thus limited?

    3) Why do I have to press END key several times to get to the bottom of a
    window (usu when there is a lot of output text from the issued command)?
    (The rio maunual says just one press.)

    4) What is the sense of
    bind 'sth' 'the_same_sth'
    ? (like 'bind / /' or 'bind /usr/ruda/a /usr/ruda/a')

    5) When I do

    cd
    mkdir a
    mntgen a
    bind lib a/b
    unmount a

    all these command finish ok, but I am left with

    bind /usr/ruda/lib /usr/ruda/a/b

    in the namespace (see the result of the 'ns' command; there you can also
    spot that after issueing the 'mntgen' command a line
    'bind /usr/ruda/a /usr/ruda/a/' appears; that relates to my 4th question;
    this bind is the one removed by the 'unmount' command).
    How can I get rid of that then?

    Thanks
    Ruda


  2. Re: [9fans] several things

    > 1) Having a window with rc and pressing CTRL+d usually closes the window.
    > However, from time to time it does not. Instead, I can see EOT (one
    > character; diagonally) written after the prompt, the window stays, I can
    > write anything into the window, but my commands are not executed. When does
    > this happen?


    this generally happens when you have mounted a fileserver which doesn't
    close all of rio's fds (inherited from the rc you terminated). rio considers
    the window active until all the fds are closed.

    > 2) Reading pwd.c I can see 'char pathname[512]' at the beginning of the main
    > function. Does it mean plan9 paths are thus limited?


    no. fileservers evaludate the path one element at a time.


    > 3) Why do I have to press END key several times to get to the bottom of a
    > window (usu when there is a lot of output text from the issued command)?
    > (The rio maunual says just one press.)


    if you notice that once you are at the end, you can press
    then and you will be at the end. so what's
    happening when you press when there's pending output
    is that you're placed at the end of the buffer but since the command
    producing the output blocked on its output, it immediately started
    outputting more data. so always puts you at the the
    *current* end of the buffer. that doesn't mean that there won't
    be data immediately available.

    > 4) What is the sense of
    > bind 'sth' 'the_same_sth'
    > ? (like 'bind / /' or 'bind /usr/ruda/a /usr/ruda/a')


    i believe this is a noop. in the case of "bind / /", look
    at /lib/namespace. consider the case where $rootdir
    isn't nil.

    > 5) When I do
    >
    > cd
    > mkdir a
    > mntgen a
    > bind lib a/b
    > unmount a
    >
    > all these command finish ok, but I am left with
    >
    > bind /usr/ruda/lib /usr/ruda/a/b
    >
    > in the namespace (see the result of the 'ns' command; there you can also
    > spot that after issueing the 'mntgen' command a line
    > 'bind /usr/ruda/a /usr/ruda/a/' appears; that relates to my 4th question;
    > this bind is the one removed by the 'unmount' command).
    > How can I get rid of that then?


    i don't think any pruning of inaccessable bits of
    the namespace is ever done. consider a program
    like ftpd which via /lib/namespace.ftp (sic) typically
    binds something like /usr/ftp/ onto /. while everything
    above /usr/ftp is unaccessable, it's not removed from
    the namespace and you can't touch it.

    ; mntgen a
    ; bind /env a/env
    ; bind /bin a/bin
    ; bind /proc a/proc
    ; bind a /
    ; ns

    consider it a security feature.

    - erik



  3. Re: [9fans] several things

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Oct 13, 2008, at 5:35 PM, Rudolf Sykora wrote:

    > Hello
    >
    > few questions:
    >
    > 1) Having a window with rc and pressing CTRL+d usually closes the
    > window. However, from time to time it does not. Instead, I can see
    > EOT (one character; diagonally) written after the prompt, the window
    > stays, I can write anything into the window, but my commands are not
    > executed. When does this happen?


    When you're running a server, such as ext2srv or dossrv. If I recall
    correctly, this was discussed before.

    > 2) Reading pwd.c I can see 'char pathname[512]' at the beginning of
    > the main function. Does it mean plan9 paths are thus limited?


    No. How many characters can be stored in an absolute pathname is
    program-dependent.

    > 3) Why do I have to press END key several times to get to the bottom
    > of a window (usu when there is a lot of output text from the issued
    > command)?
    > (The rio maunual says just one press.)


    rio windows don't scroll by default. To enable scrolling for a certain
    window, middle-click and hit scroll, or type

    echo scroll >/dev/wctl

    To make scrolling the default, edit $home/lib/profile and change every
    instance of

    exec rio

    to

    exec rio -s

    Log out and log back in.

    > 4) What is the sense of
    > bind 'sth' 'the_same_sth'
    > ? (like 'bind / /' or 'bind /usr/ruda/a /usr/ruda/a')


    Think of it as making an alias or link.

    > 5) When I do
    >
    > cd
    > mkdir a
    > mntgen a
    > bind lib a/b
    > unmount a
    >
    > all these command finish ok, but I am left with
    >
    > bind /usr/ruda/lib /usr/ruda/a/b
    >
    > in the namespace (see the result of the 'ns' command; there you can
    > also spot that after issueing the 'mntgen' command a line
    > 'bind /usr/ruda/a /usr/ruda/a/' appears; that relates to my 4th
    > question; this bind is the one removed by the 'unmount' command).
    > How can I get rid of that then?


    Delete the namespace by closing the window.

    You just found a bug; congratulations.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (Darwin)

    iEYEARECAAYFAkjz0Q8ACgkQuv7AVNQDs+yPUgCePQ1xijeQfx MC8iWZPuzNGCxH
    gCMAnR636iteBBjHhYLW4rdKjfIVIkj8
    =aCUq
    -----END PGP SIGNATURE-----


  4. Re: [9fans] several things

    On Mon, 2008-10-13 at 18:35 -0400, erik quanstrom wrote:
    > > 4) What is the sense of
    > > bind 'sth' 'the_same_sth'
    > > ? (like 'bind / /' or 'bind /usr/ruda/a /usr/ruda/a')

    >
    > i believe this is a noop. in the case of "bind / /", look
    > at /lib/namespace. consider the case where $rootdir
    > isn't nil.


    I have always thought, that the only reason for "bind "
    is so that subsequent "bind -a/-b" would work:
    http://groups.google.com/group/comp....67403b25124bac

    I would really love to be educated is there's something more
    subtle to it.

    > > 5) When I do
    > >
    > > cd
    > > mkdir a
    > > mntgen a
    > > bind lib a/b
    > > unmount a
    > >
    > > all these command finish ok, but I am left with
    > >
    > > bind /usr/ruda/lib /usr/ruda/a/b
    > >
    > > in the namespace (see the result of the 'ns' command; there you can also
    > > spot that after issueing the 'mntgen' command a line
    > > 'bind /usr/ruda/a /usr/ruda/a/' appears; that relates to my 4th question;
    > > this bind is the one removed by the 'unmount' command).
    > > How can I get rid of that then?

    >
    > i don't think any pruning of inaccessable bits of
    > the namespace is ever done. consider a program
    > like ftpd which via /lib/namespace.ftp (sic) typically
    > binds something like /usr/ftp/ onto /. while everything
    > above /usr/ftp is unaccessable, it's not removed from
    > the namespace and you can't touch it.
    >
    > ; mntgen a
    > ; bind /env a/env
    > ; bind /bin a/bin
    > ; bind /proc a/proc
    > ; bind a /
    > ; ns
    >
    > consider it a security feature.


    Be it as it may, I still can't quite follow why *manual* pruning
    of the entries from the namespace would be forbidden. unmount(2)
    takes two strings as arguments, right? It doesn't even need an fd.

    Thanks,
    Roman.



  5. Re: [9fans] several things

    > > ; mntgen a
    > > ; bind /env a/env
    > > ; bind /bin a/bin
    > > ; bind /proc a/proc
    > > ; bind a /
    > > ; ns
    > >
    > > consider it a security feature.

    >
    > Be it as it may, I still can't quite follow why *manual* pruning
    > of the entries from the namespace would be forbidden. unmount(2)
    > takes two strings as arguments, right? It doesn't even need an fd.


    because they're not visible. you have to access
    it in order to unmount it.

    - erik


  6. Re: [9fans] several things

    On Wed, 2008-10-15 at 08:17 -0400, erik quanstrom wrote:
    > > > ; mntgen a
    > > > ; bind /env a/env
    > > > ; bind /bin a/bin
    > > > ; bind /proc a/proc
    > > > ; bind a /
    > > > ; ns
    > > >
    > > > consider it a security feature.

    > >
    > > Be it as it may, I still can't quite follow why *manual* pruning
    > > of the entries from the namespace would be forbidden. unmount(2)
    > > takes two strings as arguments, right? It doesn't even need an fd.

    >
    > because they're not visible. you have to access
    > it in order to unmount it.


    I see what you meant now. For some reason, I constantly assume
    that namespace is sort of a substitution table that helps you
    walk(5) across the bind/mount points. But it is not. Is there
    a simple reason for mandating access to the target of the bind?

    Or here's an easier way to ask the same: is there a simple reason
    for
    $ bind /foo /really/nested/bar
    always triggering walks into /foo and /really/nested/bar and not
    allowing for "lazy evaluation"?

    Thanks,
    Roman.



  7. Re: [9fans] several things

    2008/10/18 Roman V. Shaposhnik :
    > On Wed, 2008-10-15 at 08:17 -0400, erik quanstrom wrote:
    >> > > ; mntgen a
    >> > > ; bind /env a/env
    >> > > ; bind /bin a/bin
    >> > > ; bind /proc a/proc
    >> > > ; bind a /
    >> > > ; ns
    >> > >
    >> > > consider it a security feature.
    >> >
    >> > Be it as it may, I still can't quite follow why *manual* pruning
    >> > of the entries from the namespace would be forbidden. unmount(2)
    >> > takes two strings as arguments, right? It doesn't even need an fd.

    >>
    >> because they're not visible. you have to access
    >> it in order to unmount it.

    >
    > I see what you meant now. For some reason, I constantly assume
    > that namespace is sort of a substitution table that helps you
    > walk(5) across the bind/mount points. But it is not. Is there
    > a simple reason for mandating access to the target of the bind?
    >
    > Or here's an easier way to ask the same: is there a simple reason
    > for
    > $ bind /foo /really/nested/bar
    > always triggering walks into /foo and /really/nested/bar and not
    > allowing for "lazy evaluation"?


    The evaluation of bind argument "happens at the time of the bind, not
    when the binding is later used." -- see bind(2).
    Also, /sys/doc/9.ps worth reading.


  8. Re: [9fans] several things

    On Mon, 2008-10-20 at 17:09 +0300, Yaroslav wrote:
    > > Or here's an easier way to ask the same: is there a simple reason
    > > for
    > > $ bind /foo /really/nested/bar
    > > always triggering walks into /foo and /really/nested/bar and not
    > > allowing for "lazy evaluation"?

    >
    > The evaluation of bind argument "happens at the time of the bind, not
    > when the binding is later used." -- see bind(2).


    That is well understood. But perhaps you've misunderstood my question
    (well, either that or I wasn't too articulate asking it). The question
    was really about *why* such a behavior was chosen to begin with? On the
    surface it seems that namespace-as-a-substitution table is not such
    a bad idea AND it adds flexibility. After all, it is trivial to emulate
    eager evaluation if you have lazy one implemented, but not the other
    way around.

    Of course, "you don't argue with Ken" (c) ;-) Which means that
    there's a pretty good reason for bind evaluation to be eager, its just
    that it doesn't seem obvious to me. Hence the question.

    Thanks,
    Roman.



+ Reply to Thread