X-Spam-Check-By: sourceware.org Date: Thu, 8 Jun 2006 22:07:35 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: cygwin non-posix problems Message-ID: <20060609020735.GB5641@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4485E5F3 DOT 7010700 AT tlinx DOT org> <20060607062254 DOT GB2592 AT efn DOT org> <4488B498 DOT 4030306 AT tlinx DOT org> <45640 DOT 38 DOT 112 DOT 225 DOT 178 DOT 1149811889 DOT squirrel AT 38 DOT 112 DOT 225 DOT 178> <20060609020358 DOT GA5641 AT trixie DOT casa DOT cgf DOT 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 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 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/