Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Date: Wed, 13 Apr 2005 01:07:56 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool Message-ID: <20050413050756.GA9643@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <041220052251 DOT 26916 DOT 425C50E800071C000000692422007507840A050E040D0C079D0A AT comcast DOT net> <20050412234432 DOT GA17857 AT trixie DOT casa DOT cgf DOT cx> <425C8966 DOT 3000802 AT byu DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425C8966.3000802@byu.net> User-Agent: Mutt/1.5.8i On Tue, Apr 12, 2005 at 08:52:22PM -0600, Eric Blake wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >According to Christopher Faylor on 4/12/2005 5:44 PM: >>On Tue, Apr 12, 2005 at 10:51:20PM +0000, Eric Blake wrote: >> >>>To some degree, the problem isn't even coreutils fault - cygwin itself >>>is where it was decided that stat(2) succeeds for either "foo" or >>>"foo.exe" when only "foo.exe" exists, but that unlink(2) fails unless >>>it is spelled "foo.exe". The implicit .exe magic I added in rm is >>>simply recognizing that if stat succeeded but unlink failed, that >>>unlink should be tried a second time with the correct extension. >> >>I'm not sure I understand this. >> >>If cygwin were made to not treat .exe specially, that would mean that, >>presumably, either you'd remove all of your patches from coreutils and >>make people use .exe specifically, or you would work around the lack of >>.exe by adding it on your own. > >Don't get me wrong - I was not asking to have cygwin's .exe magic >removed. I like having .exe automagically appended. It is much more >unix-like to be able to refer to a compiled file without an extension, >even though the underlying Windows needs the extension for exec*() to >succeed. You implied that "this isn't even coreutils fault". If it isn't coreutils fault, that would imply that cygwin was doing something wrong and that coreutils is working around something in cygwin. I don't see what that is. If we stripped out all exe handling you would still apparently put it back into coreutils. The fact that stat() finds .exe files and unlink() doesn't seems rather irrelevant to me, since you've more or less produced a wrapper around unlink() but not stat(), because stat() didn't need one. The bottom line is that whatever cygwin did or didn't do, the user would end up seeing the same behavior. 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/