[9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed - Plan9

This is a discussion on [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed - Plan9 ; Hello I encountered sth strange: being e.g. in my home ; pwd /usr/ruda I issue ; @{cd lib} then lc, pwd seems to be ok, lists/returns my home directory, but the completion with ctrl-f/ins proposes things from the 'lib' directory. ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

  1. [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    Hello

    I encountered sth strange:

    being e.g. in my home

    ; pwd
    /usr/ruda

    I issue
    ; @{cd lib}

    then lc, pwd seems to be ok, lists/returns my home directory, but the
    completion with ctrl-f/ins proposes things from the 'lib' directory.
    What's going on? I really can't live without the completion function...
    'cd .' doesn't help, only 'cd $home' does... Only then the completion
    functions again...
    Hope this will work the same for you too.
    If you know, please tell me soon.

    Ruda


  2. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    > I issue
    > ; @{cd lib}
    >
    > then lc, pwd seems to be ok, lists/returns my home directory,


    This makes sense to me - though I am not saying its "correct".

    When you cd in interactive mode rc(1) writes the path to the
    directory into /dev/wdir. This informs rio of your current dir
    so it can do the filename completion (and also gives the directory
    context to the plumber).

    I guess the @{ } "execute in a subshell" code in rc could save and restore
    the current directory, however this is only an issue in interactive mode.
    I have never needed @{ } interactively so I have not had this problem.

    probably the best way to get things back in sync is:

    cd `{pwd}

    -Steve


  3. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    Rudolf Sykora wrote:
    > > I really can't live without the completion function...


    how come? I've *never* used it


  4. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    > When you cd in interactive mode rc(1) writes the path to the
    > directory into /dev/wdir. This informs rio of your current dir
    > so it can do the filename completion (and also gives the directory
    > context to the plumber).
    >
    > I guess the @{ } "execute in a subshell" code in rc could save and restore
    > the current directory, however this is only an issue in interactive mode.
    > I have never needed @{ } interactively so I have not had this problem.


    This saving&restoring seems flawed to me due to possible race-conditions...
    I'd expect each shell had its own copy of /dev/wdir... But I may be
    easily wrong...

    > probably the best way to get things back in sync is:
    >
    > cd `{pwd}
    >
    > -Steve


    yes, that works
    Ruda


  5. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    2008/10/28 matt :
    > Rudolf Sykora wrote:
    >>
    >> > I really can't live without the completion function...

    >
    > how come? I've *never* used it


    .... this is hard to comment on...
    Ruda


  6. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    cd .

    is sufficient

    -rob


  7. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    > cd .
    >
    > is sufficient
    >
    > -rob


    As I wrote in my initial mail, 'cd .' does not help.
    Ruda


  8. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    the bug is within rio, which keeps track of changed directories but
    doesn't know that some of them are changed on a stack for a child
    process. the actual code is in xfid.c:^xfidwrite, the Qwdir case. what
    is happening is that it catches the 'cd /lib' correctly and sets
    w->dir accordingly, however the subsequent 'cd .' is interpreted as a
    local unrooted path (doesn't start with '/') and the dot is appended
    to the current w->dir. cleanname() subsequently just remove the dot,
    leaving the old w->dir to be supplied to 'complete'.

    two solutions:
    - use getpw() instead of w->dir for unrooted arguments to cd (the
    return value of getpw() is correct after the subshell command
    completes)
    - use 'cd `{pwd}' instead of 'cd .'... this will give a rooted
    argument to 'cd' and rio will reset the whole w->dir

    andrey

    On Tue, Oct 28, 2008 at 10:27 AM, Rudolf Sykora wrote:
    >> cd .
    >>
    >> is sufficient
    >>
    >> -rob

    >
    > As I wrote in my initial mail, 'cd .' does not help.
    > Ruda
    >
    >



  9. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    > As I wrote in my initial mail, 'cd .' does not help.

    pwd >/dev/wdir

    cd . works for fixing acme's tag (if your cd runs awd)
    but not for fixing /dev/wdir, because rc just writes the
    argument to cd uninterpreted into /dev/wdir, and
    /dev/wdir interprets paths relative to the current wdir setting.

    It's a hard problem in general, since the shell has
    no idea whether the program that just ran changed
    /dev/wdir. The only way to keep it in sync would
    be to force the shell to write into /dev/wdir after
    every command completed, which would be overkill.

    Russ


  10. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    > - use getpw() instead of w->dir for unrooted arguments to cd (the
    > return value of getpw() is correct after the subshell command
    > completes)


    scratch that, it is incorrect. i only tried getpw() from the shell.
    rio doesn't necessarily live in the same world as the shells in its
    windows.

    thanks to Russ for promptly correcting me.


  11. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    > This saving&restoring seems flawed to me due to possible race-conditions...
    > I'd expect each shell had its own copy of /dev/wdir... But I may be
    > easily wrong...


    When a rc forks a subshell the child shares the namespace with the parent.
    If you want the child rc to divorce its namespace from the parent, have it
    issue 'rfork n'.

    There is no race condition; this is documented behaviour.

    You need to (re-)read the namespaces paper in /sys/doc/names.ps.

    --lyndon


  12. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    > When a rc forks a subshell the child shares the namespace with the parent.
    > If you want the child rc to divorce its namespace from the parent, have it
    > issue 'rfork n'.


    This is true, but I am afraid it doesn't have much connection to the problem.
    Even if you 'rfork n' (and have a copy of the namespace) the file
    /dev/wdir is simply the same file in both namespaces...
    Ruda


  13. Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed

    > This is true, but I am afraid it doesn't have much connection to the problem.
    > Even if you 'rfork n' (and have a copy of the namespace) the file
    > /dev/wdir is simply the same file in both namespaces...


    Yes, I realized after I hit send that I wasn't very clear about what I was
    trying to say. I wasn't trying to address the wdir issue, but your
    allusion to the namespace behaviour not making sense. Knowing how
    and why namespaces work as they do is critical to understanding and using
    Plan 9. It's important that you read and understand the names.ps paper and
    then spend time experimenting with namespaces. For most people it's the
    hardest part of the system to wrap your brain around, but once you get it
    your universe gets a lot bigger very quickly.

    --lyndon


+ Reply to Thread