severity 225836 wishlist retitle 225836 Please implement "--recursive" option thanks
On Fri, 2004-01-09 at 11:29, Jim Meyering wrote: > The problem with the previous implementation is that its behavior > wasn't well defined. OK, I see the problem. Briefly put, if the symlink chain doesn't point to a non-symlink then there is no such thing as the canonical path of the non-symlink. Take pathname a/b/c/.../y/z. To convert this into the canonical path we step through the components one by one, removing "." and "*/..". When we reach a symlink we replace it with its value and check again. If at some step we arrive at a nonexistent then we fail because the pathname is ambiguous: someone could put a directory there or a symlink to some other location; these would result in different canonical paths of the final non-symlink. Thus the behavior of "readlink -f" is reasonable. It is probably best not to change it. What I need is something that works like "readlink -f" and effectively disambiguates according the rule that any missing component is replaced by a directory. This would work exactly as above except that instead of failing it would succeed and return the path as it had been converted up to that point. This is equivalent to disambiguating by assuming that the nonexistent components would be filled in with directories. I reckon that it would be fairly easy to add a new option to readlink (say, -r | --recursive) that would make it behave this way. E.g., Suppose there is no /tmp/bar but we have /tmp/foo -> bar . Then "readlink -f /tmp/foo" and "readlink -f /tmp/foo/xyzzy" will fail but "readlink -r /tmp/foo" would succeed with "/tmp/bar" and "readlink -r /tmp/foo/xyzzy" would succeed with "/tmp/bar/xyzzy". Does this make sense? -- Thomas Hood <[EMAIL PROTECTED]> _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
