Re: Corner-case bug in .exe handling?
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 signature.asc Description: PGP signature
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' 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?
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 signature.asc Description: PGP signature
Re: Corner-case bug in .exe handling?
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 158 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 112 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
