X-Spam-Check-By: sourceware.org Date: Thu, 8 Jun 2006 22:07:35 -0400 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: cygwin non-posix problems Message-ID: <20060609020735.GB5641@trixie.casa.cgf.cx> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <4485E5F3.7010700@tlinx.org> <20060607062254.GB2592@efn.org> <4488B498.4030306@tlinx.org> <45640.38.112.225.178.1149811889.squirrel@38.112.225.178> <20060609020358.GA5641@trixie.casa.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060609020358.GA5641@trixie.casa.cgf.cx> User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On Thu, Jun 08, 2006 at 10:03:58PM -0400, Christopher Faylor wrote: >On Thu, Jun 08, 2006 at 05:11:29PM -0700, Yitzchak Scott-Thoennes wrote: >>Linda Walsh wrote: >>> Yitzchak Scott-Thoennes wrote: >>>> Can he or you reduce the problem to a non-File::BOM dependent test >>>> script >>> What part of the perl module File::BOM should I throw out before >>> it's no longer File::BOM? It's just perl code. >>> >>> It's freely downloadable through CPAN, so I can't make it too >>> much more publicly available than that. >> >>The point would be to reduce the amount of code that might need >>to be inspected to find the underlying problem. Nothing to do >>with publicly available. >> >>> But FWIW, the File::BOM code isn't the actual problem. It's >>> the authors test routine that he decided to be "fancy" with, >>> and use a child process to send strings via a "FIFO" to the >>> test harness process. >>> >>> It isn't desirable to modify "cygwin-only-failing" Perl modules >>> to work around problems than only happen under cygwin. Certainly >>> you can see how that is "burying one's head under the sand". Suppose >>> various parts of CPAN are rewritten to steer around bugs in Cygwin. >>> Does that make the underlying problems problems in Cygwin go away? >>> Does that make cygwin more stable or more compatible with other >>> Posix platforms? >>> >>> In my mind it eliminates test cases that are perfectly uncovering >>> Cygwin incompatibilities and deficiencies. >> >>I agree with all of the above and wasn't trying to suggest modifying >>the tests. > >Indeed, this is standard operating procedure for debugging problems. In case this wasn't clear, I meant that winnowing down a failure to a minimal amount of code required to reproduce the problem is "SOP". cgf -- 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/