This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7.2?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]