From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <14ec7b180810281016n740bc1c3s69f17430c9a0d854@mail.gmail.com> Date: Tue, 28 Oct 2008 11:16:52 -0600 From: "andrey mirtchovski" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <41cff9c1e1818e4fa7638332331f9cc0@quintile.net> <7359f0490810280830y48505733hf970657829ded2ed@mail.gmail.com> Subject: Re: [9fans] @{cd ...} breaks completion with ctrl-f/ins; help needed Topicbox-Message-UUID: 2a25f7d6-ead4-11e9-9d60-3106f5b1d025 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 > >