On 2019-03-20 03:24, Corinna Vinschen wrote: > On Mar 19 18:02, Yaakov Selkowitz wrote: >> Just came across this with 3.0.4 on both Win7 and Win10 1804: >> >> $ ls -1 /usr/bin/python2.7 >> /usr/bin/python2.7 >> $ ls -1 /usr/bin/python[2-9].[0-9] >> /usr/bin/python3.5 >> /usr/bin/python3.6 >> /usr/bin/python3.7 >> /usr/bin/python3.8 >> >> python2.7 is the actual .exe where python3.* are symlinks, but >> shouldn't 2.7 still be included in the latter? > > No, even if that looks weird. But think about what happens. ls calls > readddir. readdir returns "python2.7.exe". The matching is not done by > Cygwin, but by the shell. And python2.7.exe simply doesn't match > "python[2-9].[0-9]". > > Nothing Cygwin can do about, unless we suppress the .exe suffix in > readdir/realpath/readlink output just like we do with the ".lnk" suffix > for the old winsymlink symlink style.
To also fix findutils and other glob interfaces, the filename with and without the .exe suffix would have to be returned to support both: find /bin/ -name '*sh' and find /bin/ -name 'sh.exe' unless you wanted to globally disallow finding any file with suffix .exe and at the same time restore the suffix in all cases where it is explicitly required? -- 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. -- 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