Corner-case bug in .exe handling?

Corner-case bug in .exe handling?

[Yaakov Selkowitz]

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?

--
Yaakov



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

Re: Corner-case bug in .exe handling?

[Brian Inglis]

On 2019-03-19 16: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?

Implicit .exe files have not been matched by coreutils or findutils for quite a
while:

$ find /bin/ -name '*sh'
/bin/config-run2-example.sh
/bin/csh
/bin/fontname.sh
/bin/fontprop.sh
/bin/gettext.sh
/bin/gvfs-trash
/bin/instmodsh
/bin/ksh
/bin/listings-ext.sh
/bin/lprsetup.sh
/bin/mkzsh
/bin/ptksh
/bin/repo2solv.sh
/bin/source-highlight-esc.sh
/bin/src-hilite-lesspipe.sh
/bin/tclsh
/bin/tcsh
/bin/texhash
/bin/unix-lpr.sh
$ ls -glo /bin/*sh
-rwxr-xr-x 1  4290 Jul 17  2013 /bin/config-run2-example.sh
lrwxrwxrwx 1     8 Nov 24  2016 /bin/csh -> tcsh.exe
-rwxr-xr-x 1  1351 Mar 28  2006 /bin/fontname.sh
-rwxr-xr-x 1   929 Mar 28  2006 /bin/fontprop.sh
-rwxr-xr-x 1  4629 Oct 23  2016 /bin/gettext.sh
-rwxr-xr-x 1   277 Feb 19  2018 /bin/gvfs-trash
-rwxr-xr-x 1  4287 Dec  1 00:28 /bin/instmodsh
lrwxrwxrwx 1     8 Mar 23  2018 /bin/ksh -> mksh.exe
lrwxrwxrwx 1    58 May  7  2018 /bin/listings-ext.sh ->
/usr/share/texmf-dist/scripts/listings-ext/listings-ext.sh
-rwxr-xr-x 1  5470 Mar  9 11:22 /bin/lprsetup.sh
-rwxr-xr-x 1  1428 May  9  2018 /bin/mkzsh
-rwxr-xr-x 1 18572 Sep 27  2017 /bin/ptksh
-rwxr-xr-x 1  7859 Mar 23  2018 /bin/repo2solv.sh
-rwxr-xr-x 1  1017 Apr 11  2018 /bin/source-highlight-esc.sh
-rwxr-xr-x 1   490 Apr 11  2018 /bin/src-hilite-lesspipe.sh
lrwxrwxrwx 1    12 Dec 29  2017 /bin/tclsh -> tclsh8.6.exe
lrwxrwxrwx 1     8 Dec  7  2016 /bin/tcsh -> tcsh.exe
lrwxrwxrwx 1     8 May  7  2018 /bin/texhash -> mktexlsr
-rwxr-xr-x 1  4131 Mar  9 11:22 /bin/unix-lpr.sh
$ ls -glo /bin/*sh.exe
-rwxr-xr-x 3 100883 Feb 17  2017 /bin/ash.exe
-rwxr-xr-x 1 739859 Jan 27  2017 /bin/bash.exe
-rwxr-xr-x 3 100883 Feb 17  2017 /bin/dash.exe
-rwxr-xr-x 1 265747 Feb 27  2018 /bin/mksh.exe
-rwxr-xr-x 1 611490 Jun 11  2016 /bin/posh.exe
-rwxr-xr-x 1  12280 Dec  7  2017 /bin/ppmflash.exe
-rwxr-xr-x 3 100883 Feb 17  2017 /bin/sh.exe
-rwxr-xr-x 1 638483 Oct 19 04:43 /bin/ssh.exe
-rwxr-xr-x 1 372755 Nov 24  2016 /bin/tcsh.exe
-rwxr-xr-x 2  10259 Dec 24  2017 /bin/wish.exe
-rwxr-xr-x 1  10771 Jul 28  2013 /bin/xrefresh.exe
-rwxr-xr-x 2  10752 May  9  2018 /bin/zsh.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.

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

Re: Corner-case bug in .exe handling?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Corner-case bug in .exe handling?

[Brian Inglis]

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

Re: Corner-case bug in .exe handling?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

On Mar 20 12:55, Brian Inglis wrote:
> 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'

Do you realize the implications?  Either every executable shows
up as two distinct files, or each executable has twice the number
of hardlinks.  Either way is bad for one scenario or the other.

> 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?

IMHO we don't change anything.  The current way of things isn't
ideal, but works more or less fine for a long time.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]