X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: mwoehlke <mwoehlke AT tibco DOT com>
Subject:  Re: Bash 3.1.17(8) CR/LF problem
Date:  Wed, 27 Sep 2006 16:02:47 -0500
Lines: 46
Message-ID: <efeotn$a48$1@sea.gmane.org>
References:  <860934040609271241ib9c7486q60b651ac9b3d6c36 AT mail DOT gmail DOT com>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0
In-Reply-To: <860934040609271241ib9c7486q60b651ac9b3d6c36@mail.gmail.com>
X-IsSubscribed: yes
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

Malcolm Nixon wrote:
> I recently updated to Bash 3.1.17(8) and found my local build system
> failing due to the removal of CR/LF support:
> "A script on a binary mount that uses \r\n line endings will probably
> encounter syntax errors or odd variable assignments, because the \r is
> treated literally.  If this happens to you, use d2u to fix the line
> endings, or change your script to live in a text mount point.  A
> script  that resides on a text mount can have either line ending (even
> inconsistently mixed), but be aware that text mount points are
> slower,  due to \r\n filtering."
> 
> Unfortunately simply running "d2u" isn't a solution because:
>    * Some revision control systems make the files read-only.
>    * Some detect the change to <LF> as changes require manual merging.
>    * Some translate files to a "Local" format (CR/LF on Windows).

At least in some cases, there is a solution to this: use a Cygwin 
version of the RCS that knows that "native" means UNIX-style. :-) This 
works great for me (although I also go so far as specifying UNIX-style 
rather than "native").

> I think the bigger issue here is that this arbitrary change will break
> a "significant" number of existing scripts. I contract for a few
> companies that use Cygwin/Bakefile to achieve support for multiple
> compilers/tool-chains, and for hourly auto-build servers. This change
> will break all of them - some of which have been functional for over 4
> years.

It won't break ours. Nor did make-3.81. We DIRTFT (Did It Right The 
First Time). :-)

> In my opinion a better solution would have been to err on the side of
> compatibility and only use the new fast readline code if manually
> enabled.

I think a better solution would be to push for upstream to patch bash 
(probably as an option via shopt or an environment var or something) to 
just ignore '\r' at the end of a line. Interix has this problem also, 
and I think Rodney's version of bash does this (I know they went through 
this same issue, and the result was a bash that could always handle 
mixed line endings - I don't think Interix has any concept of a 'text 
mode' mount so it sees scripts like a UNIX would).

-- 
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?


--
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/