[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Question on compath() in sbr/path.c
From: |
Paul Fox |
Subject: |
Re: [Nmh-workers] Question on compath() in sbr/path.c |
Date: |
Sun, 30 Jan 2005 22:49:43 -0500 |
> > > 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)