Subject: Re: Regression in .exe extension handling
From: "Yaakov (Cygwin/X)" <yselkowitz@users.sourceforge.net>
To: cygwin <cygwin@cygwin.com>
In-Reply-To: <4C292D35.6000005@redhat.com>
References: <1277766496.7412.18.camel@YAAKOV04>	 <4C292D35.6000005@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 28 Jun 2010 21:54:30 -0500
Message-ID: <1277780070.7412.231.camel@YAAKOV04>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On Mon, 2010-06-28 at 17:16 -0600, Eric Blake wrote:
> The problem is here - should install be open()ing "foo" (the script) or
> "foo.exe" (the executable) as the source file for copying into bar/foo?
>  Since it is never a good idea to have both an .exe and a script of the
> same name in the same directory, is this really a regression, or just
> bad behavior on mono's part? 

This is a regression: it worked just fine with earlier 1.7.x releases.

> Remember, libtool was recently changed to avoid exactly this ambiguity.

This is different: neither the wrapper nor assembly are executed in the
builddir; they are just created there and installed into different
locations.

> Or should I be trying to patch coreutils (and/or someone patch cygwin1.dll)
> to try harder to open the script instead of the .exe when the suffix-less 
> file conflicts with the .exe?

It's definitely a bug (or two) somewhere:

* "install foo" correctly installs 'foo' but the presence of foo.exe
apparently fools something to add the .exe.

* the .exe is being added when the file is clearly not a PE executable,
nor a link thereto.

Whether these bugs are coming from coreutils or cygwin, or both, I do
not know.


Yaakov


--
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