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:	<AANLkTil0pNuO4a9n2Ln5H3Q0cJRdQER7NlgSTg2a9EN2 AT mail DOT gmail DOT com> <OFCB72527D DOT F8E42EE2-ON8525773C DOT 0058E3E2-8525773C DOT 0059F451 AT lnotes-gw DOT ent DOT nwie DOT net> <1276042636 DOT 1651 DOT 9 DOT camel AT erebor> <AANLkTil6fa2-stL9f3hd-Dg-X6FjzVKLeG56lPoI7OYp AT mail DOT gmail DOT com> <20100609044034 DOT GB9305 AT ednor DOT casa DOT cgf DOT cx> <AANLkTikJ9U3U49HlT9Ldm6aueX3z22gN_6L95P-E2Pwz AT mail DOT gmail DOT com> <AANLkTinrgelZ5PcMhWjzehe8sa-cjkGoiFI8WpLGNh84 AT mail DOT gmail DOT com> <AANLkTikzCzig2SyG_J1dtGPDvDVCLYZyZM_TBj9fxNgm AT mail DOT gmail DOT com> <AANLkTilSrEgdrVMMMZQLZrnU1wKi-WrQt8H4_JX3B-w7 AT mail DOT gmail DOT com> <4C0FA1CA DOT 4070000 AT redhat DOT com> <20100609142828 DOT GA8163 AT calimero DOT vinschen DOT de>
From:	Julio Costa <costaju AT gmail DOT com>
Date:	Wed, 9 Jun 2010 16:00:09 +0100
Message-ID:	<AANLkTik88tX3dQ7OF8uApZnM-QMD9cxfvbB3SKt6mOrC@mail.gmail.com>
Subject:	Re: 'cp' utility bug when <dest-name>.exe file exist.
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 <application>.exe <application> :)

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

- Raw text -