Re: diff -r is not flexible in handling symlinks

[Paul Eggert]

> From: address@hidden
> Date: Wed, 24 Apr 2002 15:16:47 -0400
> 
> Well, the way I look at it is this: The fact that diff -r follows
> symlinks is unexpected.  (And IMHO buggy, but that's another matter.)

In some cases it's better to follow symlinks; in other cases it's
worse.  So I think 'diff' needs an option.

> So it ought to be explicitly noted in the documentation that diff -r
> follows symlinks.  Once you specify that, you have to add that diff -r
> detects infinite loops of symlinks and then ...  Well, what *does* it
> do when it finds an infinite loop?  Does it signal an error?

Yes.  The error message stands in the place of what would be an
infinitely long part of the 'diff' output, consisting of file
differences that have already been seen (under shorter names).  It
would be nicer if one could deduce what that infinitely-long sequence
would look like from the error message, but that isn't supported
currently.

> Does it omit comparing files that it's already seen?  Does it omit
> comparing file pairs that it has already compared?

The latter.

> One does not render diff's behavior predictable without stating how
> it deals with symlink loops.

It's not necessary to give all these details in the documentation, any
more than it's necessary to document the exact algorithm that diff
uses to generate text-file differences.  However, the documentation
could be improved along the lines suggested above.  This could be done
by whoever adds support for cp-like -H, -L, and -P options.  GNU
diffutils 2.8 supports but deprecates the obsolete 2.7 meanings for
these three options; a future version of GNU diffutils is planned to
change their meanings to agree with that of 'cp'.

> (What I'd really like to see is that diff compares symlinks by
> extracting the contents of the links and comparing them.)

Yes, that behavior should be available.  Similarly for special files,
named pipes, doors, etc.

Also, when diff is comparing a symbolic link to a regular file, you
should be able to see that one is a symlink with contents S, whereas
the other is a regular file with contents T.  However, there are
several possible behaviors here, and as far as I know nobody has had
the time to think through all the issues.