Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <5.0.0.25.2.20040406105537.00afbeb0@216.148.227.80> X-Sender: murpup AT 216 DOT 148 DOT 227 DOT 80 Date: Tue, 06 Apr 2004 11:20:55 -0500 To: cygwin AT cygwin DOT com From: Chris Murray Subject: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed FWIW, I would just like to chime in with one instance that I know of where you may have reason to expect to see files that have mixed EOL characters. The scenario is this: Person develops a code under cygwin and is really careful to ensure all files use /n endings. Person distributes said code to others. One of those individuals uses Visual Studio to edit the source files for whatever reason. They make changes, run a contextual diff to generate a patch file and submit that patch file to the developer. The lines in the context diff that detail the changes now have the /r/n EOL chars for the modified lines instead of /r that the originals had. The developer, before applying the patches will need to strip these characters to make sure the patch process works properly and doesn't introduce /r/n accidentally. It would be nice not having to create a separate tool to do this. (I wrote one in perl and would be happy to share, although it also strips out trailing whitespace and converts tabs to spaces - but that functionality could be removed rather easily) My opinion is that having a d2u tool with a --force option (or perhaps "--mixed" is a bit more conceptually consistent) is a reasonable solution to all concerned. Chris -- 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/