Re: 1.7.2?

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat