RE: 'cp' utility bug when lt;dest-namegt;.exe file exist.

2010-06-11 Thread Nellis, Kenneth
Perhaps it's worth considering adding a CYGWIN environment variable option, e.g., exe_magic, and deliberately evolve the code base towards checking this setting before invoking exe magic. I, for one, never run my binaries in the Windows environment, so exe magic has no benefit and numerous

Re: 'cp' utility bug when lt;dest-namegt;.exe file exist.

2010-06-11 Thread Steven Collins
On Fri, Jun 11, 2010 at 08:38, Nellis, Kenneth kenneth.nel...@acs-inc.com wrote: Perhaps it's worth considering adding a CYGWIN environment variable option, e.g., exe_magic, and deliberately evolve the code base towards checking this setting before invoking exe magic. I, for one, never run my

Re: 'cp' utility bug when lt;dest-namegt;.exe file exist.

2010-06-11 Thread Larry Hall (Cygwin)
On 6/11/2010 1:46 PM, Steven Collins wrote: On Fri, Jun 11, 2010 at 08:38, Nellis, Kenneth wrote: Perhaps it's worth considering adding a CYGWIN environment variable option, e.g., exe_magic, and deliberately evolve the code base towards checking this setting before invoking exe magic. I, for

Re: 'cp' utility bug when lt;dest-namegt;.exe file exist.

2010-06-10 Thread Eric Backus
Eric Blake writes: A first step would be teaching gcc to not append .exe. Many configure scripts (certainly almost all scripts based on autoconf) determine $(EXEEXT) based on gcc behavior, and will just do the right thing throughout the rest of the build with $(EXEEXT) empty (as evidenced by

Re: 'cp' utility bug when lt;dest-namegt;.exe file exist.

2010-06-10 Thread David Antliff
On Fri, Jun 11, 2010 at 10:26, Eric Backus wrote: As a side note, this same kind of reasoning is why I think Cygwin bash should default the igncr option to on. I agree - using git with core.autocrlf=true (a controversial setting in itself, but one that you're stuck with if you choose to use it)