On 2020-09-09 08:25, Eliot Moss wrote: > On 9/9/2020 12:57 AM, [email protected] 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.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
