From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) by sourceware.org (Postfix) with ESMTPS id A11E0385782D for ; Wed, 9 Sep 2020 17:31:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A11E0385782D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id G3vzkQ7GF62brG3w0kzrnO; Wed, 09 Sep 2020 11:31:04 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=AcdjiWDHAAAA:8 a=hEh3JUyyAAAA:8 a=Ed7FdIT4gc43trk-okQA:9 a=QEXdDO2ut3YA:10 a=jDsUxUaHaGUzR5dRE_q_:22 Reply-To: cygwin@cygwin.com Subject: Re: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities To: cygwin@cygwin.com References: <72243122-9da4-1631-4912-04580c70ea3c@EMail.com> <5F582F25.3040301@tlinx.org> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 RSyTY8X+AQ== Organization: Systematic Software Message-ID: Date: Wed, 9 Sep 2020 11:31:03 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfEF9IiqKtXzsEcGG/NMEdtNQwqRrazlUelTOeNA4uAnzobb+deK7mS2yFEVCWuH8KNhkgtdjAhuAJZnDRQcunhcZkjWWlHz/OQwEv001g3WM0uhMHwYt uglLeNjg9C+qs6Hn02TkX1lzoqWnWYesRBNvZ4rm9jqfwsZLtmkHUHIp8iVnTStmOIehVPcfwpmkOg== X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2020 17:31:07 -0000 On 2020-09-09 08:25, Eliot Moss wrote: > On 9/9/2020 12:57 AM, JohnBush@EMail.com wrote: >> I appreciate your reply outside the scope of the cygwin alias. Sorry I am >> having issues with the alias.   I'll change to a gmail address soon because >> I'll bet that the *mail.com* server is bogusifically filtering my outgoing mail. Looking at your original content, you have unindented, unprefixed Unix commands at the starts of lines, so the malware checker probably classifies your email content as a potentially malicious surreptitious script hack. Try indenting your command lines and prompt prefixing them and all should be well. >> I understand the reasoning in transparifying the .exe suffix;  I suspected >> this was an incurable windows host environment issue, but didn't fully fathom >> how embedded this nuance is in the overall nature of everything. >> >> If I come up with a workaround, I will let you know.    I'm going to write a >> simple C program that calls *lstat()*.   I hope this links beneath where the >> error is produced in the command environment.   If my experiment works, I'll >> send you the code.   If not, well, it's been nice chatting, and I will be out >> of your hair. :-) >> >> Thanks also Eliot Moss who replied separately. > I think the intention is that this be entirely transparent at the > library interface.  It is a behavior intentionally placed deep within the > libraries.  Maybe there's some edge case kind of way that will reveal that foo > does not really exist and only foo.exe is there, but that would be because for > some reason the Cygwin core could not hide it. > So I expect writing your own C code to call lstat is not going to change > things.  This is > not a bash behavior but a Cygwin behavior, deep in the library code. > > If you really really need to look and see the difference, then you can use > Windows calls to do so -- but rather than going that route, why don't you lay > out your use actual use case to the Cygwin community?  Why is it you think you > need to see around this?  Often there are other ways to achieve your overall > objective that go more smoothly.  At least that's my experience with situations > where people are rubbing up against an intentional design ... As anyone who has run a Cygwin strace knows, Cygwin suffix additions check for .exe, .lnk, and .exe.lnk, and so you should not have a file or directory and file with the same basename and one of those suffixes in the same directory. The check is performed in symlink_check at a low level. If the name is sufficiently long to be unique, you can bypass suffix addition within a directory at the command line glob by prefixing the basename with a wildcard: $ ls /bin/*bash ls: cannot access '/bin/*bash': No such file or directory $ ls /bin/bash /bin/bash $ ls /bin/bash.exe /bin/bash.exe -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]