Re: [Nmh-workers] Question on compath() in sbr/path.c

[Paul Fox]

 > > > 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, address@hidden (arlington, ma, where it's 23.0 degrees)