side effects after installing gcc-3.4.4.999

Dave Korn dave.korn.cygwin@googlemail.com
Tue Mar 3 03:42:00 GMT 2009


Akakima wrote:

> I agree 99.99 % with you.  :-). the 0.01 is about would you please not 
> totally forget that cygwin is running on a Win32 platform. (no offense
> here, no joke, no disrecpect, ...)

  Absolutely, no offence taken, and I'm sorry if my earlier post seemed that I
had done so.  We of course don't want to forget that we're running on win32,
and I don't want to do anything to needlessly break using Cygwin apps directly
from win32, but I even more don't want to do anything to hold back the
completeness and improvement of the POSIX side of things for the sake of the
win32 side.  Fair?  :-)

> Technicaly it's not DOS, but the WinXP command prompt window. This windows 
> behave like a DOS console but this is not a DOS application. This a win32
> application using a rather feature limited subset of the winapi. (sorry if
> you already know this).

  Yes; what I meant by that distinction was that you're running the "cmd.exe"
shell, which is the modern-day equivalent of DOS, inside a text-mode console
window, as opposed to running a Cygwin shell (which can be run in a text-mode
console window *or* in a GUI terminal like rxvt).  The point is about the
environment from which applications are launched, not the console used.

> Yes, it is a good idea. I already have a set of batch files that fix the 
> PATH an other environments variables depending with what compiler i am
> working with. setcygwin.cmd for Cywin setmingw.cmd for MingW etc...
> 
> This works quite well. Each new instance of the cmd.exe can have its own 
> set of variables.

  Writing yourself a few simple scripts/batch files like this is definitely
the way to make your life easier when trying to manage these
potentially-conflicting environments.

>> somewhere and you don't see it. Maybe launching subprocesses causes all
>> the buffers to be flushed through in the first case.
> 
> I dont know and i dont know how to test that.

  Sorry, I was just thinking out loud, that wasn't meant to be useful as an
idea for testing!

> Conclusion: this is related to the way cmd.exe process and run the target
> of the shortcut. Shortcuts are normally ran from the explorer. I guess
> bash is a little more intelligent.

> That would be perfect, because with all the good settings, the change would
> be completly transparent. If cmd.exe was not the culprit. As illustrated.

>>  Is that how it's happening for you?
> 
> Yes!. Exactly.
> I tried many variants to launch the shortcut. Each time, the results
> are the same.
> 
> Thanks for taking the time to verify this.  If i find a solution
> i will report it here.

  That would be good, thank you.  It may be that there's nothing you can do.
Then again, it may be a sign that we're missing a flush somewhere in the
Cygwin DLL.  Are you trying with 1.5 or 1.7?  If you haven't tried 1.7 yet,
you can give it a go; follow the instructions in the most recent announcement
posting, and it's simple to try out a parallel installation that doesn't mess
with your current 1.5 setup.

  In the meantime, I suggest that you don't worry too much about it.  The
compiler works, every command you enter is executed, and the only thing wrong
is that the prompt goes missing somehow.  That hopefully won't break any of
your scripts or batch files.

    cheers,
      DaveK


--
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