On Wed, 8 Jun 2005, Matthew Miller wrote:
On Wed, Jun 08, 2005 at 09:05:59AM -0600, Robin Laing wrote:
> I looked through the man bash and I see the issue but it doesn't fix
> the problem. If you are in a linked directory and want to cp or mv a
> file using the linked paths, it just does not work. If you set the -P
> option (as I understand it) you are moved to the actual directory and
> pwd would show this. In my opinion, I would expect symlinks to act as
> actual directories and the paths would follow those issues.
The problem is: if you're in a symlinked directory, what is ".."? How do
programs know how you got there -- all they know is the current working
directory. And it'd be kinda bizarre (and in some cases defeat the *point*
of using symlinked directories) if the answer depended on where you came
from.
I find that commands will usually admit that symlink/. is a directory.
If one wants to write an application that
uses the symlinked version of one's path,
one could read it using FILE *getsym=popen("pwd -L", "r");
All the ..'s in a file name could be eliminated with text editing.
--
Mike hennebry(a)web.cs.ndsu.NoDak.edu
"There are three kinds of people,
those who can count and those who can't."