gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: windows/linux interop status - line endings?


From: John A Meinel
Subject: Re: [Gnu-arch-users] Re: windows/linux interop status - line endings?
Date: Wed, 30 Mar 2005 10:34:42 -0600
User-agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324)

Anand Kumria wrote:
On Mon, 28 Mar 2005 14:25:30 +1000, Robert Collins wrote:


On Sun, 2005-03-27 at 19:00 -0800, Tom Lord wrote:

The issue is garbage: it's residual from early mudslinging between the
MSFT world and everyone else, afaict.

Stick something in your makefiles if you're stuck with line-ending issues.

Bitch to your MSFT tool vendors -- logically, albeit it not economically, they
are the odd man out.

For all that, I think something consistent is needed. If in ones
archive, you want unix line endings, but have contributors on older
macos machines, and on windows machines, then you have to deal with
toolchains on each platform being different. (I know of 3 different
ASCII line ending formats that have been in widespread use).

The one common point of interchange is the RCS. I think it has to be
there that the solution is hooked in, whether its native to the RCS or
not.


Isn't diff being used to determine whether a file is binary? If it is then
the appropriate fopen mode with 'b' tacked on should make things work for
both text and binary, no?

Anand

I think you misunderstood his argument. He wants tla to translate the
line endings before committing the changes. So that all files in the
repository are LF, though the ones in the local directory might be CR,
CRLF, or LF depending on your platform. That is how CVS does it.

I'm advocating to *not* change line endings. That is the --binary flag
to diff and patch. It has no effect on Linux, which doesn't do anything
with CRLF, but on Windows without the flag it strips the CRLF on
reading, and always creates it on writing.
Except if you are using cygwin, and you have your default line ending
set to LF, in which case it always strips the CRLF, and then outputs LF.
Which causes problems on files that you *want* to be CRLF because other
tools require them, but you want most of your files to be LF.

John
=:->

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]