Re: "readlink -f foo" fails if the target of foo does not exist

[Thomas Hood]

On Mon, 2004-03-22 at 20:48, Dmitry V. Levin wrote:
> I'd suggest to leave current "readlink -f" behaviour unchanged.
> If you need to add new mode for readlink(1), please consider adding
> new option.


The difference with the current readlink appears only in a case
that the existing readlink(1) man page does not describe -- the
case where the target file does not exist.  We want to extend
the program at this undocumented margin.

In Debian, at least, the behavior of the readlink program is not
established by tradition either.  The readlink program in
woody behaved like Miquel's new readlink program: it printed the
canonicalization of a symlink chain without requiring that the
chain point to an existing file.

The new program is consistent with the ordinary behavior of the
readlink program.  When you have a symlink foo and you run:

    readlink foo

the program does not fail if the target of foo fails to exist.
The program simply prints the value of symlink foo.  In the same
manner the new program gives the canonicalized value of a symlink
chain without requiring that the target of the chain exist.

The new program conforms to the documentation for the realpath()
and canonicalize_file_name() functions that exist in various
places including stdlib.h and the info for readlink.  (That those
functions don't conform to their documentation is another issue.)

The new readlink program is more useful than the current readlink.
The current readlink can't tell you the canonical name that a
file would have if it were created through a symlink chain whereas
the new readlink can tell you that.  On the other hand, the
current readlink is easily emulated using the new readlink.  In sh
code:

    [ -f $ARG ] && new-readlink -f $ARG

Jim Meyering wrote[1] on the bug-coreutils list in January that he
would be happy to apply a patch that restored this feature of
the "old" readlink implementation.  I don't know the history but
I gather that the old readlink program was buggy and the feature
in question disappeared when the program was rewritten.  Now
Miquel has rewritten it again in such a way that the feature is
restored.  I don't see this as a disruptive change.

[1]http://mail.gnu.org/archive/html/bug-coreutils/2004-01/msg00053.html

Of course, if a consensus is reached here that the current behavior
of "readlink -f" must not be changed then of course it wouldn't be
hard to modify the new readlink such that "-f" works as it does
currently and the print-path-even-if-target-doesn't-exist behavior
is turned on by some other option.

-- 
Thomas Hood <address@hidden>