X-Spam-Check-By: sourceware.org
Date: Fri, 16 Dec 2005 21:09:14 +0200
Message-Id: <uvexooo4l.fsf@gnu.org>
From: Eli Zaretskii <eliz AT gnu DOT org>
To: Lennart Borgman <lennart DOT borgman DOT 073 AT student DOT lu DOT se>
CC: cygwin AT cygwin DOT com
In-reply-to: <43A2DDC7.9080802@student.lu.se> (message from Lennart Borgman on 	Fri, 16 Dec 2005 16:31:19 +0100)
Subject: Re: Patch and Cygwin
Reply-to: Eli Zaretskii <eliz AT gnu DOT org>
References: <SERRANOMu3QTYCrtU2b00000042 AT SERRANO DOT CAM DOT ARTIMI DOT COM> <43A1ACC1 DOT 9090805 AT student DOT lu DOT se> <43A1B2A1 DOT 2020907 AT student DOT lu DOT se> <43A20542 DOT 1050405 AT student DOT lu DOT se> <uoe3hphdk DOT fsf AT gnu DOT org> <43A2834A DOT 8000900 AT student DOT lu DOT se> <ud5jxp9n4 DOT fsf AT gnu DOT org> <43A2DDC7 DOT 9080802 AT student DOT lu DOT se>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

> Date: Fri, 16 Dec 2005 16:31:19 +0100
> From: Lennart Borgman <lennart DOT borgman DOT 073 AT student DOT lu DOT se>
> CC: cygwin AT cygwin DOT com
> 
> Eli Zaretskii wrote:
> 
> >What's wrong with the patched file having CRLF on Windows?
> >  
> >
> It is the default line endings on Windows so normally that is what you 
> want. However if you have a file with LF line endings instead then don't 
> you probably have that for a reason?

Whatever my reasons are (see below), Patch supports that setup as
well: just make sure all the patch files are in Unix format, and use
the "--binary" switch to Patch.

> I am not for example convinced that all cvs implementations on Windows 
> can handle that a checked out file has got changed line end format.

The ports I've seen all strip CRs when they send files to the server,
and add CRs when they checkout files.  However, the desire not to
depend on that is one of the reasons I checkout with -kb.  That, and
the fact that the ported CVS adds an extra CR to each line of batch
files and other files stored in DOS EOL format, which causes all kinds
of strange failures during Emacs build (I'm sure you remember these
problems discussed on the Emacs development list).

> >But why should I care about these strange combinations on Windows?
> >Why isn't it enough that patching Unix-style files with Unix-style
> >patch files works (using --binary) and preserves the EOL type, and
> >patching DOS-style files with DOS-style patch files also works?
> >  
> >
> I do not know if you should care, but I do. It just happened to me that 
> things did not work because of one of these other non-working 
> combinations did occur for me.

There are two combinations that work: when all files have DOS EOLs,
and when they all have Unix EOLs (and you use --binary switch).  Stick
to these two simple combinations (use dos2unix or unix2dos if you have
other mixtures of file formats), and you should be safe.

> >Why the perfectionism?  If the usual cases work so well, why do we
> >want to insist on looking for trouble at all costs?
> >
> I hope it is not perfectionism. If you like me do many different things 
> with a computer you are likely to get into cases like those I have as 
> test cases. I can hardly touch a computer without finding something that 
> does not work on it ;-)

Do you need to do actual work on the computers you play with?  I do,
and I value my time, so I try to keep out of pitfalls that can take a
better part of the day to get out of.

> >Because I can find no other explanation for the fact that the test
> >that failed for you worked for me.  Maybe you should try installing
> >all the utilities again, make sure what Diff and what Patch runs in
> >each command, and see whether gnuwin32-test.cmd indeed fails for you.
> >  
> >
> Could we be misunderstanding each other? Which test case worked for you 
> but failed for me?

The file gnuwin32-results.txt indicates that the gnuwin32-test.cmd
test failed for you; it did not for me (I reported my results
earlier).

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/