Tue Mar 2 21:09:00 GMT 2010
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
> 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.
I still think that rename(2) should keep the first category of exe magic
(if exe was implicitly used to resolve the source, then it should be
automatically added to the dest); no one has been complaining about that.
Eric Blake email@example.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 320 bytes
Desc: OpenPGP digital signature
More information about the Cygwin-developers