Re: make/tests issues

[Eli Zaretskii]

> Date: Sat, 06 Mar 2004 15:19:16 +0000
> From: "J. Grant" <address@hidden>
> 
> So only DJGPP ignores the CRLF/LF distinction.

No, not only the DJGPP port, _any_ native port to DOS/Windows does
that.  The only exception I know of is Cygwin.

> diff v2.8.1 (from
> GNU/Linux package diffutils-2.8.1-3mdk) differentiates the CRLF/LF line
> endings the same as I experience on MSYS.

The question is how Diffutils was compiled.  When it is compiled on
DOS/Windows systems, it normally ignores the line endings because the
library functions it uses to read files remove the CR characters.
That is why you will not see anything in the Diff sources: the
conversion isn't there to begin with.  And that is why on GNU/Linux,
there's no conversion: GNU and Unix systems use the LF-only line
endings, so their library functions leave the CR characters intact.

> I am using MSYS-1.0.8, which is a fork of an older version of cygwin I
> believe.  Have you tried this?  (http://mingw.org/)

So I'd guess that this problem is inherited from Cygwin which indeed
tried to emulate Unix on Windows by using Unix-style binary I/O with
text files.  As you have discovered, this approach is troublesome.

It is possible that there's some tool in the MSYS package that will
``mount'' the disk drive you are using in ``text'' mode (as opposed to
the probably default ``binary'' mode).  That should cause Diff to
strip CR characters, and your problem should go away.

Failing that, you will have to ask for help on the MSYS-related
forums, as I don't use MSYS and cannot help you.  I'm standing by my
previous opinion that any Diff port to Windows that doesn't strip CR
characters by default is broken.

> I do not think diff should ignore by default

Why not?

> So if diff process the way you prefer, when it ignores CRLF/LF
> differences do you think the output patch should have the formating
> forced to LF?  Otherwise new text may have CRLF in the patch, and the
> original file might have been LF format.

This is not a problem, assuming that the ported Patch utility also
uses text-mode I/O by default (GNU Patch also has the --binary switch
that overrides that).  It works like that: Patch reads both the patch
file and the original file in text mode, which strips the CR
characters if they are found.  Then both the patch file and the
original file in memory have only the Unix-style LF-only lines, and
the patch will apply.  Patch then writes out the patched file in text
mode, which has a side effect of making its lines end in the DOS-style
CRLF pairs.  Unless you mind that (DOS/Windows compilers also strip
CRs, so this is in general not a problem), all's well.

Bottom line: with text-mode reads, it is not important whether the
file or the patch have DOS- or Unix-format lines.  Which is why it is
always better for text-processing programs to use text-mode I/O on
DOS/Windows, especially when the files involved come from both Unix
and Windows.