1.7.2?

[Larry Hall (Cygwin Developers)]

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?

-- 
Larry