This is the mail archive of the
mailing list for the Cygwin project.
Re: Bug with Cygwin's 'quilt' is actually in 'patch'
- From: "Peter B." <tripleshiftone at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 03 Jul 2013 17:33:49 +0200
- Subject: Re: Bug with Cygwin's 'quilt' is actually in 'patch'
- References: <51D39491 dot 9040501 at email dot com> <20130703123326 dot GF5118 at calimero dot vinschen dot de> <51D42171 dot 9010701 at email dot com> <20130703133048 dot GG5118 at calimero dot vinschen dot de>
On 03.07.2013 15:30 Corinna Vinschen wrote:
> On Jul 3 15:04, Peter B. wrote:
>> On 03.07.2013 14:33 Corinna Vinschen wrote:
>>> On Jul 3 05:03, Peter B. wrote:
>>>> On Jun 20 09:46, Corinna Vinschen wrote:
>>>>> I'll build a new patch 2.7.1 for 32 bit today. I hope that fixes it
>>>>> for 32 bit as well.
>>>> The new 2.7.1 (32bit) brakes CRLF handling for me completely. The old
>>>> 2.6.1 works properly. 2.7.1 with text files converted from CRLF to LF
>>>> works properly as well.
>>>> Can you take a look at the download link below? It includes an example
>>>> file (with CRLF), the corresponding patch (LF) and the two binaries
>>>> (patch v2.6.1 and v2.7.1).
>>> Please provide a direct link which doesn't require to enable scripting
>>> in a web browser to download.
>> Please download this picture (jpg) and rename the file suffix to 7z or
>> open with corresponding archiver directly.
>> http://abload.de/img/patchfus75.jpg (99KB)
> Thanks. The behaviour here is a deliberate upstream choice to apply the
> patch only if the line endings are the same as in the file to patch.
> If you really must apply non-CRLF patches to CRLF files, consider using
> a temporary text mount:
Sounds like intended behavior. I will try to tackle the problem
The culprit here is the JavaVM that produces different
EOLs on different platforms (running a binary decompiler -> txt).
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple