.exe magic

Dave Korn dave.korn@artimi.com
Wed Apr 18 10:20:00 GMT 2007

On 18 April 2007 09:49, Charles Wilson wrote:

> Eric Blake wrote:
>> Interesting thought.  But it is more than just cygwin 1.7.0 that would
>> have to be changed; we would also need a new release of gcc that no longer
>> added an automatic .exe to files as they are compiled.  And there might be
>> some severe repurcussions in automake/autoconf where they currently are
>> coded to handle $(EXEEXT) all over the place, if they do it based on
>> hostname rather than on what the default gcc output is.  I would have to
>> remove some of the .exe magic I've added in coreutils (but it would mean
>> I'm closer to an upstream image). 
> Um, some people actually launch cygwin tools from outside a shell, via
> shortcuts.  Like, say, rxvt, or run, or bash.  I think the windows
> subsystem still requires known extensions in order to start new
> processes (%PATHEXT%=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH)

  Yes, it certainly does.  This use case is still important to me and I
suspect to many others.

> And even if that were not a problem, I still suspect that making a
> drastic change like that will have many far-reaching, non-obvious, and
> deleterious effects.

  Hear, hear.  I don't think anything so drastic as this should be attempted
without a deprecation period of a year or so for the old behaviour.  And in
fact I think it would probably transpire to be a serious limitation on the
utility of cygwin.  Remember, if you just want "Linux on windows", you'll get
a much better emulation by installing a VMware machine, and it's faster too.
A lot of Cygwin's 'added value' comes from interoperating in a single unified

Can't think of a witty .sigline today....

Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

More information about the Cygwin mailing list