Re: On darwin, diff <(echo ab) <(echo cd) does nothing

[Paul Eggert]

Vincent Lefevre <address@hidden> writes:

> Instead of checking the file name (vs /dev/fd/*), one can say that
> if a file is a fifo, then the files are different. Even if two fifos
> were the same file, I think it is a bug not to read them, since this
> is an optimisation that has a side effect.

I think it depends on what one wants.  For example, suppose d is a
directory and you do something like this:

   mkdir e
   ln d/* e
   touch e/newfile
   diff -u d e

I would expect to see:

   Only in e: newfile

even if there is a fifo in d.  That is because I want to see the
difference in the directory structure, and I don't want diff to read
the fifo twice.

This is a semantic issue: should "diff X X" be required to read X
twice, or should it be allowed to read X just once?  Similarly for
"cmp X X".  John Cowan's point about "diff /dev/tty /dev/tty" also
bears on this issue.  "diff - -" is similar: currently GNU diff
outputs nothing even if standard input is a tty.

As far as I can see, POSIX requires the optimization in question.  For
diff it says that "no output shall be produced if the files are
identical" and for cmp it says that it "shall write no output if the
files are the same".  However, since Solaris cmp and diff do not have
the optimization I suppose Sun doesn't agree with this interpretation.

Perhaps POSIX should be clarified in this area; someone could file an
interpretation request I suppose.  In any event, clearly portable
programs should not care one way or another.


> I had a similar problem in the past with cp and a NAS, where the
> backup file in the .snapshot had the same device and same inode as
> the normal file (as the dates were different, this would not be a
> problem for diff, which is more paranoid that cp, which just checks
> the device and the inode values).

In general, cp must avoid the time stamp checks, since it must deal
with the possibility that the file is mutating as it is being copied.
diff and cmp have the luxury of assuming that the inputs are read only.


>> In the meantime, how about if diff looks at the st_mtime too
>> (including the nanoseconds component)?
>
> It already does this.

No, it is not looking at the nanoseconds component.  If it did, would
that fix the problem for you?  I'm afraid you'll have to test this, as
I don't have access to your environment.