On Tue, 30 Jan 2024 at 00:28, Junio C Hamano [off-list ref] wrote:

Adam Dinwoodie [off-list ref] writes:

quoted

quoted

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.