Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Message-ID: <008301c33a9a$5c5e89e0$030200c0@DJ0X820J>
From: "Antoine Levy-Lambert" <antoine@antbuild.com>
To: "Ant Developers List" <dev@ant.apache.org>
Subject: copy with filtersets modifies lineendings
Date: Tue, 24 Jun 2003 23:48:33 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0080_01C33AAB.1F5DB780"

------=_NextPart_000_0080_01C33AAB.1F5DB780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Windows, I am copying a file which has lineendings ending \n, using a =
filterset.
The output has \r\n as line endings. (Actually, I am using cygwin; the =
CVS client of cygwin retrieves files coming from ant's CVS with \n and =
not \r\n as line ending.)


This is similar to the bug report of Peter Reilly "copy with filtering =
modifies line endings"
http://issues.apache.org/bugzilla/show_bug.cgi?id=3D18476

Now, in this bug report, Peter wrote "I can sort of understand why =
copying with filtersets modifies line endings".

Do we want to leave it that way, or do we want to slightly change the =
implementation of copying with filtersets, so that the line endings of =
the original files are preserved ?

Currently, I have the corresponding test FilterSetTest failing under =
cygwin, which is bad. (I am after failing tests under Windows, including =
under the combination Windows/cygwin).


Cheers,

Antoine
------=_NextPart_000_0080_01C33AAB.1F5DB780--