On Tue, 30 Jan 2024 at 00:28, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Adam Dinwoodie <adam@xxxxxxxxxxxxx> writes: > > >> Hmm, good point. It seems like the answer should obviously be "yes", but > >> Windows CI seemed to pass all the same (and I checked that it indeed ran > >> the unit tests). Do we only get the $X suffix for MSVC builds or > >> something? Looks like maybe cygwin, as well. > > > > Cygwin will automatically append ".exe" when doing directory listings; > > a check if the file "a" exists will return true on Cygwin if "a" or > > "a.exe" exists; a glob for "a*" in a directory containing files "a1" > > and "a2.exe" will return "a1" and "a2". This causes problems in some > > edge cases, but it means *nix scripts and applications are much more > > likely to work without any Cygwin-specific handling. I *think* this > > logic is carried downstream to MSYS2 and thence to Git for Windows. > > Interesting, especially that "a*" is globbed to "a2" and not > "a2.exe". My error, sorry! I've just double-checked and Cygwin's globbing will report the file with the .exe extension. I clearly misremembered how this works. Having looked up a bit more of the implementation is simply that, if Cygwin tries to open a file named "x" and doesn't find it, it will attempt to open "x.exe" before it returns the failure. This means that scripts that call (say) `/usr/bin/env bash` or `cat` or `[ "$x" = "$y" ]` or whatever will broadly Just Work(TM) rather than needing to be rewritten with the extension added. But the behaviour only applies when Cygwin is looking for a specific filename.
