X-Spam-Check-By: sourceware.org Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Similar Bash 3.1.18 CR/LF Problem Date: Wed, 4 Oct 2006 13:06:19 -0400 Message-ID: <4C89134832705D4D85A6CD2EBF38AE0F7B137A@PAUMAILU03.ags.agere.com> In-Reply-To: <20061004114807.GE30609@trixie.casa.cgf.cx> From: "Williams, Gerald S \(Jerry\)" To: Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id k94H6cLl020630 Christopher Faylor wrote: > The dilemma here is that I read other mailing lists besides > cygwin where people are trying to use Cygwin but are close > to giving up because it is so slow. So, making bash faster > for people who are using it correctly is very desirable. Which is why we need to get the patch in upstream. If you can't make it faster, you can at least make what you're comparing against slower. :-) Seriously, I'd have a hard time believing that supporting endings would noticably impact performance if it were done as part of upstream BASH. Special-casing Cygwin (especially when you start doing things like checking for DOS paths, examining the first line, etc.) would impact performance, surely. So I agree--don't do that. gsw -- 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/