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
environment.
cheers,
DaveK
--
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/
