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

[Scott Blachowicz]

>  > I guess that I don't understand your answer.  You seem to be looking at the
> 
> i think he's offering an analogy.

An example, but more variations that necessary to illustrate the point :).

>  > 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

With that example and using my shell (usually zsh, but others do this too),
the sequence of commands:

        cd /b/foo
        cd ..

puts me in /b, NOT in /a.  That's because, as Paul mentions:

> 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 "pwd" command is a shell built in command that can use the knowledge kept
by the shell about how its user got to the current directory (e.g. "cd /b/foo"
in the example above) and can interpret ".." as meaning what you would expect
by looking at the directory handed to "cd".

The "/bin/pwd" command is an external command that doesn't necessarily know
how the user got to the current directory.  It probably just has something
stored in the process describing the real on-disk directory and uses that
without knowing how the process actually got to that dir.

> 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".

You could probably make a counter argument that if someone knows how symlinks
work, this behavior is surprising :).  But I think that the number that would
expect "/b/foo/.." to land you in "/a" would be small.  So maybe that should
be "principle of least surpise for the largest audience" :).

I have a feeling it could also give you odd behavior in an environment
using an automounter like "amd" (which uses what looks like symlinks some).
For example, if a /home dir is run by an automounter, the /home dir would look
like a bunch of symlinks to the actually mounted location.  So, /home/user1
might link to /a/host1/home/user1 and /home/user2 might link to
/a/host2/home/user2.  Then if you cd to /home/user1/../user2 you don't get to
the right place if you do the ".." from the /home/user1 target dir.

Where is this compath function used?  If in the location of mail folders, I
think you might want the current behavior anyways.  So that if your current
folder is "/home/user1/Mail/lists/nmh-workers" and you tried to reference a
folder relative to your current folder, you don't have to worry about where
you might have partitioned a large folder off to?

Scott