This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Corner-case bug in .exe handling?

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'


	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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]