> 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,
With that example and using my shell (usually zsh, but others do this too),
the sequence of commands:
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?
Nmh-workers mailing list