From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103022 invoked by alias); 12 Sep 2016 23:30:55 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 103012 invoked by uid 89); 12 Sep 2016 23:30:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=HMime-Version:2104, H*UA:2.2104, HMime-Version:8.2, H*x:2.2104 X-HELO: mail-qt0-f182.google.com Received: from mail-qt0-f182.google.com (HELO mail-qt0-f182.google.com) (209.85.216.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Sep 2016 23:30:44 +0000 Received: by mail-qt0-f182.google.com with SMTP id l91so63534768qte.3 for ; Mon, 12 Sep 2016 16:30:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=iGop9zSodoER4zLIFD1D4w75j9+sJ2bIQeAmtormmX8=; b=AxcapvHNwarKvvsDHV0qGhuPe31AQ/aRd32MUPnJfE03OnaMv/XzFgjLkr7vewZZ6E 0ziXIHNSp5xpLkysPT6Ugc3J7kEhw240SoDSOe1M+iHiNe7BYfKoGk6n24ncfF2TDtXq fwKzDfYJGMtu93VEPFsH2uFq2P2f2u8adVjF3zvX89z31H74VWzqyOFsP9SQipAEptfw LEvzoM/xBHfThInw/Xz4BL87RN5luiPEWeOk5CcFxK2gxAnfdfF4wm24adp2TJlnUSwI MJV+PAJlb0he3cNVubKRh/B9cW6WnsVc7489p9MwqlHqYsCVg1gEGxzyOqXUocYr/usJ CWfQ== X-Gm-Message-State: AE9vXwOjeeiVLz+xOxfgF62opM8VbVdvg7yf+SYSfxv6PXSZisV19PiWtLmKfz6tQEo1bQ== X-Received: by 10.200.38.147 with SMTP id 19mr23858293qto.67.1473723042414; Mon, 12 Sep 2016 16:30:42 -0700 (PDT) Received: from [192.168.9.23] (CPE00fc8d49b393-CM00fc8d49b390.cpe.net.cable.rogers.com. [72.137.114.94]) by smtp.gmail.com with ESMTPSA id g16sm11964194qke.23.2016.09.12.16.30.41 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Sep 2016 16:30:42 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: unzip, find broken by auto handling of .exe file extension From: Stephen Anderson In-Reply-To: Date: Mon, 12 Sep 2016 23:41:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D13B45DBC02439BB6983CB46A306103@skywavemobile.com> <0D835E9B9CD07F40A48423F80D3B5A704BB9586B@USA7109MB022.na.xerox.net> <493DBECE9DB54588A55BDB6921F73079@skywavemobile.com> To: cygwin@cygwin.com X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00188.txt.bz2 > On Sep 12, 2016, at 4:53 PM, Marco Atzeri wrote: >=20 > On 12/09/2016 21:12, Stephen Anderson wrote: >> Thanks Ken, good observation. >>=20 >> -----Original Message----- >>> From: Nellis, Kenneth >>> From: Stephen Anderson > >>> > See also: >>> > >>> > http://stackoverflow.com/questions/32467871/unzip-gives-checkdir-erro= r- >>> > directory-exists-but-is-not-a-directory#32468314 >>> > >>> > The fact that 7z handles this and unzip does not indicates that the >>> > problem is fixable.. >>=20 >>> FWIW, it seems that the same issue is present with tar: >>> >>=20 >> This means that you can't reliably extract from a tar or zip archive in >> cygwin. >> The windoze equivalents do not have this problem. >> It looks to me like the approach of equating filenames 'foo' and >> 'foo.exe' is dangerous at the stat(2) level - apparently windoze >> accomplishes the same trick in a much less destructive way. >>=20 >> sja >>=20 >=20 > This characteristics is needed as windows for historical reason > requested ".exe" extension for all executable files, while > Unix have not such restriction. >=20 > So "cat.exe" is recognized by cygwin also as "cat". > Without this feature all scripts taken by traditional Unix's will > be broken and cygwin will be unusable. >=20 > Try this experiment on Linux: >=20 > touch foo > mkdir foo >=20 > does it work ? This is not relevant, there is no foo, there is only foo.exe. In the case of windows _command_ processing, certain extensions are searche= d for automatically without creating an equivalency in file names. This mea= ns that for the same directory and filename hierarchy, windows and linux ar= chive processing work, cygwin uniquely fails. Not a desirable outcome. IMHO the only time cygwin should be looking for .exe (or .cmd, .bat etc if = desired), is when no match is found on loading a _command_, possibly only f= rom a shell. sja -- 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