> > > 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, [EMAIL PROTECTED] (arlington, ma, where it's 23.0 degrees) _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
