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: Thu, 5 Oct 2006 10:22:11 -0400 Message-ID: <4C89134832705D4D85A6CD2EBF38AE0F7B13ED@PAUMAILU03.ags.agere.com> In-Reply-To: <20061004232458.GB14493@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 k95EMYow015489 Christopher Faylor wrote: > You haven't been paying attention, it seems. > > We've already been over this ground. The performance impact > for turning on bash's automatic CRLF handling is profound. > That's why we're here. I guess WJM around here. :-) But perhaps I've been paying more attention than you think. If a patch is incorporated into upstream BASH, it's not going to cause performance problems. If it did, it would be rejected. That's something for the upstream maintainers to decide. I may be coming at this from a different angle, to be sure. I'm not really interested in a Cygwin-specific solution--I don't particularly want the ability to write scripts that can't run under Linux. 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/