X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.2 required=5.0	tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_YG
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Andrew DeFaria <Andrew AT DeFaria DOT com>
Subject: Re: tar deletes .exe files on extraction (again)
Date: Fri, 23 Sep 2011 08:34:19 -0700
Lines: 95
Message-ID: <j5i8ts$994$1@dough.gmane.org>
References: <DDC20689-EA66-49D5-A120-6AC40BE05900 AT blighty DOT com> <4E7BE736 DOT 1060008 AT cygwin DOT com> <4E7C9DF7 DOT 2090200 AT cs DOT utoronto DOT ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
In-Reply-To: <4E7C9DF7.2090200@cs.utoronto.ca>
X-Stationery: 0.7.5
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
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 09/23/11 07:55, Ryan Johnson wrote:
> On 22/09/2011 9:56 PM, Larry Hall (Cygwin) wrote:
>> On 9/22/2011 4:57 PM, Steve Atkins wrote:
>>> In the process of trying to build Qt on Windows in a cygwin shell, I've
>>> discovered that neither tar nor unzip will work reliably under Cygwin -
>>> untaring an archive will not correctly create the files that the 
>>> archive
>>> contains. The "configure.exe" that's required to build Qt is never 
>>> extracted
>>> from the tarball.
>>>
>>> The problem is that the cygwin filesystem shims consider "configure" 
>>> and
>>> "configure.exe" to be almost the same, despite their having different
>>> filenames, so when tar extracts an archive containing both it ends up
>>> deleting the existing "configure.exe" when it creates "configure".
>>>
>>> This was discussed a couple of years ago -
>>> http://cygwin.com/ml/cygwin/2009-08/msg00293.html - and the conclusion
>>> seemed to be that cygwin was working as designed, and the user just
>>> shouldn't ever be doing anything that requires both "foo" and "foo.exe"
>>> under cygwin, and that if they do want to do that, they probably 
>>> shouldn't
>>> be using cygwin.
>>>
>>> That seems like a fairly nasty limitation / bug, and makes use of the
>>> cygwin shell a bit too brittle to rely on for build automation - I'm
>>> wondering if anyone knows if there's been any change in the 
>>> situation since
>>> then?
>>
>> No, no change and probably not likely to be anytime soon.  By using the
>> Windows build environment for QT, you're trying to force a Windowsism 
>> into
>> Cygwin's POSIX environment.  The transparency of the ".exe" extension is
>> already a concession to a Windowsism, namely that executables must 
>> have a
>> .exe extension.  Cygwin needed to support this one though to make 
>> allot of
>> POSIX scripts work without alteration.  That may cause breakage in 
>> corner
>> cases like the QT Windows build environment but that's the (far) 
>> lesser of
>> two evils.  Cygwin's striving to provide a POSIX environment in a Win32
>> environment after all.  I know nothing about the QT build environment 
>> but
>> from what you've said, it doesn't sound like it's assuming a POSIX
>> environment for building on Windows.  I'd recommend sticking with tools
>> that conform to the Windows requirements if you're building for Windows.
>>
>> That said, going forward, there may come a day when all Cygwin 
>> executables
>> no longer have the .exe extension, which was really an interoperability
>> concession to Windows 9x/Me platforms.  Cygwin 1.7 doesn't support 
>> 9x/Me, so the concession is now largely a historical one and could 
>> possibly be
>> changed.  But even if it were to happen, it would be a big 
>> undertaking due
>> to the number of Cygwin packages that would be affected (i.e. all).  It
>> would take quite a while to trickle down to the majority of 
>> packages.  And
>> only at that point might it make sense to remove the transparent 
>> handling
>> of exe.  So that brings me back to my opening statement. :-)
> Wild speculation here...
>
> A quick test shows that ./a indeed works fine inside cygwin whether 
> the '.exe' is present or not, though it would be a little challenging 
> invoke such binaries directly from Windows.
>
> So... how hard would it be to provide 
> "CYGWIN=(no)disabletransparent_exe"?*** There could a very simple 
> utility, similar to rebaseall, which strips the .exe extension from 
> cygwin executables (identifiable from cygcheck or their presence in 
> standard paths), and which accepts additional paths to clean up. 
> People needing the functionality would be responsible run the utility 
> properly (after installing new packages, don't mess with Windows 
> paths, etc.).
>
> That would require no changes to any package to give the desired 
> behavior, and as packages change they would just fit right in (no .exe 
> in the package ==> no fuss).
>
> Of course, SHTDI...
>
> Ryan
>
> *** The old, removed "transparent_exe" has the wrong boolean sense to 
> work the correct way by default
>
What do you do about say, Foo.c and foo.c?
-- 
Andrew DeFaria <http://defaria.com>
Give a person a fish and you feed them for a day; teach that person to 
use the Internet and they won't bother you for weeks.


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