> 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

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

how come? I've *never* used it

> 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

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

cd .

is sufficient

-rob

> cd .
>
> is sufficient
>
> -rob

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

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

> 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

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

> 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

> 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

> 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