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
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
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 savingrestoring 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
Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed
cd . is sufficient -rob
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 [EMAIL PROTECTED] wrote:
cd .
is sufficient
-rob
As I wrote in my initial mail, 'cd .' does not help.
Ruda
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
Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed
This savingrestoring 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
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
