> But I could be making that up (and I'm sure someone will enlighten me
> further...)
Hi! :)
The thing to realize here is that cd's behavior with respect to symlinks
is *always* dependent on the shell you're using. 'cd' is, of course, a
shell builtin, and it can do some fairly complex things if your shell is
smart enough.
Ken, your example with 'foo' and '/var/foo' is bash's default behavior.
Would I be wrong to guess that you were using bash on your own machine
when you typed up that example?
No shell I'm familiar with cares whether a symlink points to a different
filesystem or not. (That's not what happens naturally with the chdir()
system call, and why bother implementing it in a shell? That is, who
would it help?)
The difference in Ken's examples is, I *think*, just different shells
(bash vs. tcsh). If my guess is wrong there, let me know, and I'll
come up with a more complex hypothesis. :)
bash's default behavior generally does what you want, if you want to
forget that symlinks are there in the first place:
tick:~% bash
[bayern@tick bayern]$ cd cs490
[bayern@tick cs490]$ pwd
/home/accts/bayern/cs490
[bayern@tick cs490]$ cd ..
[bayern@tick bayern]$ pwd
/home/accts/bayern
tcsh's behavior, by default, is simpler:
tick:~% cd cs490
tick:~/cs490% pwd
/home/classes/cs490/class/bayern.shawn.bayern
tick:~/cs490% cd ..
tick:/home/classes/cs490/class% pwd
/home/classes/cs490/class
This is more "natural" in that the shell isn't doing anything special.
You can modify tcsh's behavior by setting the 'symlinks' shell variable.
Setting it to 'ignore' *almost* mimics bash's default behavior, though not
perfectly. One difference is that 'pwd' is a builtin in bash, while tcsh
calls the real program. Thus, you can get into annoying situations in
bash like this:
[bayern@tick cs490]$ pwd
/home/accts/bayern/cs490
[bayern@tick cs490]$ /bin/pwd
/home/classes/cs490/class/bayern.shawn.bayern
I hope that explains it! I can't tell how coherent I really am right now. :)
Shawn