X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Tue, 27 Apr 2010 19:07:55 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: exec*() bug Message-ID: <20100427230754.GA13912@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4BD74C9E DOT 8040100 AT redhat DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD74C9E.8040100@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: 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 Tue, Apr 27, 2010 at 02:44:14PM -0600, Eric Blake wrote: >On Linux, 'env ./.' triggers an exec() that fails with EACCES, and exits >with status 126 (file was located, but cannot be executed). But on >Cygwin, the exec() fails with ENOENT, and env exits with status 127 >(file could not be located). This is particularly insidious, because >some programs depend on knowing the difference between the two types of >exec() errors (not present, vs. not executable). For example, one test >of the findutils testsuite fails, because 'echo | xargs /' gives the >wrong status. That's an easy one to fix. The code was already trying to do the right thing but it was confused by .exe handling. I've checked in a fix and am generating a snapshot now. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple