According to Corinna Vinschen on 3/2/2010 1:52 PM:
IIUC the idea is to drop the entire .exe appending from rename, right?
If so, we have to do all that .exe magic in mv(1) again, too.
Yes, but doable - I still have the patches that I used in cygwin 1.5, and
can port them forward to modern coreutils against cygwin 1.7.2 as needed.
There's also install(1) which just "forgets" to append a .exe to
installed executables if the -s option isn't given. I think this is
because install just copies and only the integrated strip call performs
the rename which automagically appends the .exe suffix. It would be
nice if that could be fixed somehow as well, while we're at it.
install is part of the coreutils, so it is in the same boat as cp and mv.
So, maybe we should just add an cygwin_internal hook for now which allows
to disable .exe appending?
OK, so I see two different scenarios - appending .exe on the dest because
it was implicitly used on the source, and appending .exe on the dest
because the source was poorly named without .exe even though it is
PE-COFF. The former is much more common (many scripts, Makefiles, and
common command line usage expect to be able to do things like 'cp
/bin/dash /bin/sh'); the latter is where we are running into problems,
where defaulting either way hurts the other camp of users (svn would need
to suppress an undesired exe, while strip wants to append exe without
extra work).
Eric, I would like to hear your opinion as well. As coreutils
maintainer this entire rename(2) thingy affects you probably more than
any other package maintainer.
One thing that made my life hard in 1.5 was figuring out whether an
implicit .exe was in play in the first place. I haven't really played
enough with cygwin_conv_path to see if it meets my needs, but even a
cygwin_internal function that could quickly answer whether "foo" really
meant "foo.exe" under the hood would be helpful.