Re: Q: On Windows why not ignore CRLF?

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> Date: Fri, 02 Jun 2017 15:56:51 -0400
> 
> FYI, I don't know how "good" this is for testing requirements but on my
> Windows systems I've installed Git for Windows (along with Perl of
> course) and that provides a number of UNIX commands which is why I
> think many of the tests work even though the recipes use lots of UNIX
> code.  Also I have no idea what the shell settings are during these
> tests; maybe it finds the Git for Windows sh and uses that.

Beware: the Unix commands that come with Git for Windows, and are
found under the usr/ subdirectory of your Git installation directory,
are MSYS builds.  MSYS is a fork of Cygwin, so (a) those commands are
not native Windows programs, they use a separate (and very large)
substitute of runtime instead of msvcrt.dll; and (b) they generally
behave like Unix programs, in particular their default is to use
binary I/O, i.e. they do NOT convert CRLF to newlines and back, as
normal Windows C runtime would.

(The bulk of Git itself, those programs under the mingw64/ or mingw32/
subdirectory, are by contrast native Windows programs compiled by the
MinGW port of GCC and using the Windows C runtime.)

It is okay to use MSYS builds of Unix tools to run the test suite, I'm
doing the same with Gawk.  You just need to be aware of the above
gotcha, and make the necessary allowances.  For example, while most
Unix commands will produce text files with only the LF characters at
their EOLs, once you invoke Make itself, it will, of course, generate
Windows style CRLF EOLs.  So comparing files with cmp, for example, is
not a good idea; better do it with "diff --strip-trailing-cr" (I
actually have a shell script called 'diff' which invokes the "real"
diff with that switch -- works like a charm).

HTH