Re: Bug in tcsh or procfs?

Adam D. Bradley (bradley@cs.unca.edu)
Thu, 19 Dec 1996 11:09:21 -0500 (EST)


[straight to the interesting part]
> omicron:/proc/1/root# pwd
> /
> omicron:/proc/1/root# ls
> System.map . . .
> omicron:/proc/1/root# ls --inode -L -d .
> 2 ./
> omicron:/proc/1/root# cd ..
> omicron:/proc/1# pwd
> /

This is normal behavior. ".." is a directory entry pointing to "the
directory above me", so we would expect "/.." to just point to "/".

> I find this highly peculiar, though I just realized that it could be tcsh
> doing some tricks here. cd is a builtin, meaning that tcsh does it own
> internal hacking of it's pwd. It could be that the pwd buffer isn't
> getting managed properly.

The pwd/cwd is usually handled by the kernel (see /proc/[pid]/cwd). cd is
normally a wrapper for a call to chdir().

> But when I do a 'set symlinks=chase' I get:
>
> omicron:/proc/1# cd root
> cd: No match.

Try this in /proc/1 and you might get the results you expect.

> ...ad infinitum as above. Settings symlinks=expand works perfectly, going
> into /proc/1/root and coming back out cleanly. bash does things correctly
> in its default configuration.
>
> ...so... Any ideas as to what's happenning? Seems like a shell bug to
> me, but is it fingering anything in the proc filesystem?

Being able to back out across symbolic links is a shell trick, I don't
think any of the filesystems support it internally.

Adam

--
He feeds on ashes; a deluded mind has led him    Adam Bradley, UNCA Senior
astray, and he cannot deliver himself or say,             Computer Science
"Is there not a lie in my right hand?"   Isaiah 44:20
        bradley@cs.unca.edu       http://www.cs.unca.edu/~bradley      <><