Jon Steinhart <jon(_at_)fourwinds(_dot_)com> wrote:
One of the tests (second one under case '.') looks for a trailing /.. on a
path. It would convert a path of /foo/bar/.. to /foo.
This doesn't seem correct to me. It works unless bar is a symbolic link.
A /.. after a symbolic link climbs up the tree on the link target side of
things, not the link name.
Depends on how you look at it. You can argue that it's doing the "right
thing" from the user's point of view...the same way that some shells track ho
w
you actually get to a directory and interpret ".." as being go up a dir level
along the path you took to get there. That is, in those shells, you do this:
% cd /foo/bar
% pwd
/foo/bar
% /bin/pwd
/files1/local-software/foo/linux/bar
% cd ..
% pwd
/foo
% /bin/pwd
/files1/local-software/foo
% ls -l /foo
.... foo -> /files1/local-software/foo
% ls -l /foo/bar
.... bar -> linux/bar
if you get my drift (and I didn't make any typos :)).
So two questions: Should I fix it and what's the correct fix? If it
should be fixed, the only thing that I can see doing is to remove this
section of code because there's no requirement that the path passed to
compath() exists, making it impossible to test the path elements.
My guess is that it doesn't really need fixing...
Scott
I guess that I don't understand your answer. You seem to be looking at the
results of ls, not the results of changing directories. Let's say that I have
two filesystems /a and /b. There is a directory /a/foo. I cd to /b and do a
"ls -s /a/foo ." If I now do a cd /b/foo/.., I end up in /a, not /b. This
isn't just a function of the shell, it's what chdir(2) does. But, the
compath() function in nmh will convert thet path /b/foo/.. to /b, not /a.
I think that this is a mistake that needs fixing; this code was probably
written before symbolic links existed.
Jon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers