X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,SARE_RMML_Stock10,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <20100609142828.GA8163@calimero.vinschen.de> References: <1276042636 DOT 1651 DOT 9 DOT camel AT erebor> <20100609044034 DOT GB9305 AT ednor DOT casa DOT cgf DOT cx>

<4C0FA1CA DOT 4070000 AT redhat DOT com> <20100609142828 DOT GA8163 AT calimero DOT vinschen DOT de> From: Julio Costa Date: Wed, 9 Jun 2010 16:00:09 +0100 Message-ID: Subject: Re: 'cp' utility bug when .exe file exist. To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 Wed, Jun 9, 2010 at 15:28, Corinna Vinschen wrote: > On Jun =C2=A09 08:14, Eric Blake wrote: >> On 06/09/2010 08:08 AM, Andy Koppe wrote: >> >>> More importantly, a lot of build scripts likely depend on the .exe b= eing added automatically. >> >> >> >> Hm. Maybe they shouldn't. >> > >> > Yeah, but "shouldn't" never stopped anyone, hence any transition would >> > certainly not be pain-free. >> >> A first step would be teaching gcc to not append .exe. =C2=A0Many config= ure >> scripts (certainly almost all scripts based on autoconf) determine >> $(EXEEXT) based on gcc behavior, and will just do the right thing >> throughout the rest of the build with $(EXEEXT) empty (as evidenced by >> their behavior on Linux). >> >> But even with that gcc change, we'd have to keep .exe magic in >> cygwin1.dll until everything in the distro has been rebuilt without an >> .exe suffix. >> >> However, I'm starting to like the idea, if we can get buy-in from the >> gcc packager. =C2=A0Dave? > > I seriously doubt the advantages. =C2=A0Cygwin will have to support .exe > for the next couple of years anyway. =C2=A0There are too many applications > out there already using the .exe suffix. Of course they are. for them: mv .exe :) Humour aside, all the *specifics* that could be spread all over a bunch of applications (and I believe they are a bunch!) are also some patches which are only contributing to deviate from the "pristine sources", and the build OOTB nirvana... That is not to say that there will be many other patches which are of course needed, but you can't say that if this were to be implemented it would be a step closer in the "POSIX purity" way. > There are too many people > out there expecting "foo" to start "foo.exe". They will be still starting foo.exe when they write foo. Because foo is foo, now. > There are too many > applications calling stat before exec which will fail. One patch less, then. Because such thing clearly could not belong to the POSIX original code. > To me this > all is a moot discussion for the very minor benefit to allow a file > "foo" alongside of a file "foo.exe". > That's not really the benefit we are all aiming, just a nice consequence of a broader objective, POSIX compliance. But I DO see that there are agitated waters if we go this way... Maybe it's just a question of managing these transformations in a phased way, but in the end, it's your call, of course. There are already some proposals in this thread, which seems to be of value, namely the one by Eric regarding gcc... With that and some minor tweaks to add the aforemented PATEXT and ASSOC "hacks", could open the way to then, slowly, removing the "magic" spread over those applications... and only in the end, in cygwin. --=20 ___________ Julio Costa -- 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