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

[Vincent Lefevre]

On 2005-08-21 20:01:48 -0700, Paul Eggert wrote:
> 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".

But what are identical files?
  1. Files that have the same absolute pathname?
  2. Files that have the same device and inode?
  3. Files that have the same contents?

According to

  http://www.opengroup.org/onlinepubs/007908799/xbd/glossary.html

a file is:

  An object that can be written to, or read from, or both. A file has
  certain attributes, including access permissions and type. File
  types include regular file, character special file, block special
  file, FIFO special file and directory. Other types of files may be
  supported by the implementation.

But the word "identical" often refers to the contents of an object.
Since diff compares the file contents, I would not exclude (3).
I would reject (1) for obvious reasons.

Also, see the context:

(from http://www.opengroup.org/onlinepubs/007908799/xcu/diff.html)

  The diff utility will compare the contents of file1 and file2 and
  write to standard output a list of changes necessary to convert
  file1 into file2. This list should be minimal. No output will be
  produced if the files are identical.

It really says "compare the contents of file1 and file2". So, even
if the files are identical, the contents should be compared. The
3rd sentence just gives precision concerning the first two, and is
just about output (not about whether the files are read or not).

> 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.

This is also a semantic issue.

http://www.opengroup.org/onlinepubs/007908799/xcu/cp.html says:

  If source_file references the same file as dest_file, cp may write a
  diagnostic message to standard error; it will do nothing more with
  source_file and will go on to any remaining files.

IMHO, the word "references" implies that the contents are not
considered for this point. And this paragraph also says: "it
will do nothing more", meaning that the file isn't even read.
So, I think coreutils cp behaves correctly, and you're right
about the time stamp checks (I didn't think about that).

> >> 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.

OK, I thought that (s)->st_mtime == (t)->st_mtime was sufficient,
as I didn't see the #define for st_mtime.

> 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.

I've modified system.h to have:

#ifndef same_file_attributes
# define same_file_attributes(s, t) \
   ((s)->st_mode == (t)->st_mode \
    && (s)->st_nlink == (t)->st_nlink \
    && (s)->st_uid == (t)->st_uid \
    && (s)->st_gid == (t)->st_gid \
    && (s)->st_size == (t)->st_size \
    && (s)->st_mtime == (t)->st_mtime \
    && (s)->st_mtimespec.tv_nsec == (t)->st_mtimespec.tv_nsec \
    && (s)->st_ctime == (t)->st_ctime)
#endif

and this indeed fixes the problem.

-- 
Vincent Lefèvre <address@hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA