Re: cmp in test scripts

[Tim Van Holder]

On Fri, 2002-01-25 at 14:47, Earnie Boyd wrote:
> > > No it isn't.  "hello, world\n" is the same size in both worlds.  "hello,
> > > world\r\n" is the same size in both worlds.  A properly ported cmp would
> > > be a better method.
> > 
> > It IS properly ported.  cmp is supposed to compare file DATA (on a
> > per-byte basis).  As such it HAS to distinguish between DOS text, Mac
> > text and Unix text (and whatever other forms are there), because the
> > FILES differ.
> > 'diff' on the other hand, is supposed to show differences in a file's
> > CONTENTS, which is a higher-level concept.  For it, text is text, and
> > line endings don't necessarily have to count as different.  As such,
> > diff (or diff -a, if that's a portable option) is better at determining
> > difference between text files than cmp.
> 
> I agree with everything you've said except for suggesting diff as a
> better solution than cmp and that the problem resides with autoconf. 
> The problem as you pointed out isn't cmp.  The problem is the files of
> reference.  It is often customary to need to convert from unix line
> endings to dos line endings and vice versa before operating on files
> from the differing platforms so the burden is still yours.  You may want
> to consider modifying the program that's creating the files you're
> comparing to open files in what is known as `binary mode' so that the \r
> isn't prepended to the \n when writing the file.

Certainly, I agree with that.  I wasn't suggesting that autoconf
absolutely HAS to use diff; I was simply pointing out that diff, not
cmp, is the tool of choice for comparing file contents.

So it boils down to what test is required: usually, for non-binary
formats, the test is whether or not the contents of the generated file
match that of the expected value, not that the file is necessarily
identical.  For example, if you're on a multibyte system, a text file
may be generated in multibyte encoding.  cmp would likely fail there
too, while a properly ported diff should treat both types of text
equally.  In such a case, requiring the user to convert all text to
single-byte would probably be excessive (as it might seriously restrict
the available character set).  And such a conversion, if done at all,
should only occur during the test phase, not during normal operation.
In that situation, simply using diff instead of cmp will DTRT; otherwise
you'd have to figure out a) which platforms might require a conversion
first, and b) what program(s) to use for such a conversion.

> I speak from experience.  I know that the problem can be rectified from
> the user side.  I use autoconf and friends on a DOSISH platform daily.

So do I.

> You need to find where the real problem resides.  You need to stop the
> \r\n garbage from being generated.  It can be done.

It can be, indeed.  I'm not sure, however, that it is the right course
of action in this particular circumstance.  Besides, handling it at the
user side would encourage local, platform-specific patches.  Using
'diff' on the package side would make it work out-of-the-box.