[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Question on compath() in sbr/path.c
From: |
Jon Steinhart |
Subject: |
Re: [Nmh-workers] Question on compath() in sbr/path.c |
Date: |
Sun, 30 Jan 2005 16:48:57 -0800 |
> Jon Steinhart <address@hidden> 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