X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Bash 3.1.17(8) CR/LF problem
Date: Wed, 27 Sep 2006 20:57:58 +0100
Message-ID: <011b01c6e26f$3abdead0$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <860934040609271241ib9c7486q60b651ac9b3d6c36@mail.gmail.com>
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

On 27 September 2006 20:42, 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:

  So why isn't using a textmode mount a solution?

>     * Some revision control systems make the files read-only.

  Huh?  You mean, permanently?  How are you supposed to edit them?  You don't
need an RCS for a read-only file that can't ever be changed, you can just burn
a copy to CD.

>     * Some detect the change to <LF> as changes require manual merging.

  What, on lines that you /haven't/ edited locally?  That's just a bug.

>     * Some translate files to a "Local" format (CR/LF on Windows).

  FCOL, what on earth does an rcs think it's playing at, tampering with your
data?  Any rcs that doesn't give you back exactly what you put into it is just
plain buggy.  Nobody asked for a "automatically mangle my data whether I want
you to or not" feature.

> I think the bigger issue here is that this arbitrary change will break
> a "significant" number of existing scripts. 

  YM a "significant" number of /broken/ scripts.  Try running any of them on a
linux box and see what you get.

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

  Then according to your opinion, everyone else in the world has to suffer
from crippled bash performance because you can't be bothered to fix your
systems.  Better for /you/ maybe, but it's not always all about you.  In MY
opinion, a better solution would be to err on the side of efficency, and only
use the old slow readline code if manually enabled.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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