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
how
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
i think he's offering an analogy.
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
right. but it's not necessarily the most expected behavior. if
i cd into a directory, and then cd back up, i have some
expectation of ending up where i started. and that's what most
shells do for me today when confronted with symlinks, even though
a strict chdir interpretation (as you point out) would take me
somewhere. likewise, the output of "pwd" and "/bin/pwd" are
often different these days, and it's important to understand what
they both do. the question is whether the compath() function
you're referring to is supposed to be offering a strictly
accurate version of path traversal, or a view that caters to the
"principle of least surprise".
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.
yes -- it probably was. and so it might be argued that it should
continue to remain blissfully ignorant of their pitfalls. ;-)
paul
=---------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 23.0 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers