delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2011/09/23/16:03:59

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Andrew DeFaria <Andrew DOT DeFaria AT tellabs DOT com>
Subject: Re: tar deletes .exe files on extraction (again)
Date: Fri, 23 Sep 2011 13:03:13 -0700
Lines: 44
Message-ID: <j5iom1$nib$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> <j5i8ts$994$1 AT dough DOT gmane DOT org> <B537E8D3-F689-469E-AC87-FBC9FE442281 AT blighty DOT com> <j5igbl$usl$1 AT dough DOT gmane DOT org> <2A62C54E-AD21-4B4E-9261-19F0F6AA01F3 AT blighty DOT com> <j5ik6l$q3c$1 AT dough DOT gmane DOT org> <AF1A3800-8AEF-4F8D-86E4-B73BEB600ED5 AT blighty DOT com>
Mime-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
In-Reply-To: <AF1A3800-8AEF-4F8D-86E4-B73BEB600ED5@blighty.com>
X-Stationery: 0.7.5
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 9/23/2011 12:07 PM, Steve Atkins wrote:
> On Sep 23, 2011, at 11:46 AM, Andrew DeFaria wrote:
>
>> On 9/23/2011 11:26 AM, Steve Atkins wrote:
>>> I'm talking about developers of applications, not cygwin-using end users. The developers could work around it (by not including .exe bootstrap files in cross-platform packages or being careful with naming), but they don't because it's not an issue that would ever occur to them, unlike case-insensitivity.
>>>
>>> Many systems are case-insensitive
>> Really? Aside from Windows what other systems are case insensitive?
> The default HFS+ on OS X is the big one for unixy developers (but there's also OS/2 HPFS, ISO9660, most of the Amiga filesystems, VMS and I think RT-11 :) ).
Such popular and current systems! Amiga? Seriously?
>>>   It's a niche environment, and not used by many developers who target a unix-style environment, so most developers packaging software will not be aware of the issue and won't work around it.
>> I don't think I've met many developers who target a Unix-style environment who did not know about Cygwin and, if forced to use Windows, use Cygwin. Granted the foo vs. foo.exe thing is a bit obscure, but I'd say that a Unix developer actually naming something .exe is also pretty rare.
> For a pure unix developer, sure. For a cross-platform developer maybe less so.
The fix is simple, probably less keystrokes than your last two 
responses... Oh, excuse me. You were not seeking a solution. Never mind 
then...
>>> Treating "foo" and "foo.exe" as equivalent is a very non-unixy thing to do
>> Neither is naming some thing with a .exe at the end!
> Sure it is. I can use any string I like to name a file! :)
You can - but why would you? Generally people don't tack on a .exe 
unless they are trying to say something. What are they trying to say?
> (And I have seen it done with some CAD apps in the dim and distant past where the actual executable was /opt/foo/bin/bar.exe which was called from a wrapper script shell /opt/foo/bin/bar. Slightly odd, sure, but not entirely silly.)
By "slightly odd" and "dim and distant past" I'd say it's not all that 
frequent nor much of a problem by definition. Why then do you appear to 
fight for it so? It's beyond me. But good luck!
>>> ("everything is a file, and the name of the file isn't important to the kernel") so it's particularly surprising behaviour on a system that otherwise looks quite like a unix environment.
>>>
>>> (I'd assumed that cygwin worked by intercepting execve(), and it hadn't even occurred to me that it would modify filesystem access at a coarser level than that until I started diagnosing apparent bugs in tar).
>>>
>>> It's not a serious problem, of course - but it does mean that the most widely used cross-platform GUI library cannot be unpacked on cygwin and built from source without jumping through hoops. Given that the cygwin environment is very attractive to cross-platform developers I'm betting I'm not the first person who has been burned by this, and won't be the last.
>> So why don't you ask them to fix it?
> Because it's not their bug, and it's something that'll pop up elsewhere too. (Note that I'm not asking anyone working on cygwin to fix it either, just reporting the issue, asking if my understanding of the bug is correct and current, then sticking around for the conversation.)
Hmmm... OK, so if you don't want them to fix it, nor want Cygwin to fix 
it, I'll assume the conversation is pretty much over at this point.
>> I mean what do they need a foo and a  foo.exe for anyway?
> configure is a shell script that does what configure always does. configure.exe is a windows binary that does much the same thing for a windows platform.
So when untarring in Cygwin, which one wins? If configure the shell 
script then my guess is we don't have a problem. So it must be that the 
Windows .exe is overwritting the shell script. Hmmm... What's a old 
bearded, pure Unix guy from Amiga/VMS land doing packing a Windows .exe 
into a tar! He oughta be tarred! And feathered! ;-)
-- 
Andrew DeFaria <http://defaria.com>
Always remember you're unique, just like everyone else.


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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019