Larry Hall (Cygwin Developers)
Wed Mar 3 03:39:00 GMT 2010
On 3/2/2010 4:33 PM, Corinna Vinschen wrote:
> On Mar 2 14:09, Eric Blake wrote:
>> 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.
> Wasn't that just calling stat("foo.exe") and check if the inode numbers
> are the same?
>> 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.
> I'm not sure I really understand your two scenarios. To me they sound
> identical. Here are the "magics" as implemented in rename right now:
> rename ("foo.exe", "bar") renames foo.exe to bar (deliberately)
> rename ("foo", "bar") renames foo.exe to bar.exe
> rename ("foo", "bar") renames foo to bar.exe
> IIUC you want to keep the first and the second, but not the third?
> That would break strip and in turn also install -s if $(EXEEXT) is
> missing in a Makefile. And on the commandline. Sigh. That was one
> of the common scenarios I hoped to fix by this.
OK, here's a heretical question - Do we need to add '.exe' anymore?
I know, 'cmd' still wants executable files with that extension (which
I'll admit may be _the_ reason to keep it) but is there anything else
that really needs it?
More information about the Cygwin-developers