X-Spam-Check-By: sourceware.org From: "Dave Korn" To: Subject: RE: Similar Bash 3.1.18 CR/LF Problem Date: Wed, 4 Oct 2006 18:10:57 +0100 Message-ID: <01ff01c6e7d8$0f1367c0$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4C89134832705D4D85A6CD2EBF38AE0F7B137A@PAUMAILU03.ags.agere.com> 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 On 04 October 2006 18:06, Williams, Gerald S (Jerry) wrote: > 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. That's a total non-sequitur. A piece of code will have the same impact, whether it's included directly in the upstream sources, or whether it's a cygwin local patch surrounded by #ifdef __CYGWIN__. 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/