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 was
> 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 n
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 p
> - 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
> 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.
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 t
> cd .
>
> is sufficient
>
> -rob
As I wrote in my initial mail, 'cd .' does not help.
Ruda
cd .
is sufficient
-rob
> 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 rest
2008/10/28 matt <[EMAIL PROTECTED]>:
> 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
Rudolf Sykora wrote:
> I really can't live without the completion function...
how come? I've *never* used it
> 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 fi
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 func
13 matches
Mail list logo
