Re: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

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