To: cygwin AT cygwin DOT com
From: "Akakima" <akakima33 AT gmail DOT com>
Subject:  Re: side effects after installing gcc-3.4.4.999
Date:  Mon, 2 Mar 2009 21:47:08 -0500
Lines: 153
Message-ID: <goi5q5$tv0$1@ger.gmane.org>
References:  <gofr4i$s1t$1 AT ger DOT gmane DOT org> <49AB8757 DOT 90807 AT gmail DOT com> <gogt3h$56g$1 AT ger DOT gmane DOT org> <49AC2ECA DOT 7040709 AT gmail DOT com>
Reply-To: "Akakima" <akakima33 AT gmail DOT com>
Mime-Version:  1.0
Content-Type:  text/plain; 	format=flowed; 	charset="iso-8859-1"; 	reply-type=original
Content-Transfer-Encoding:  7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com


"Dave Korn"  wrote:

> Windows will do because that's outside my control.  (And I don't 
> think it
> would make sense to avoid using Linux features in Cygwin just so 
> that stuff
> will work from DOS!)

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, ...)

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

>  Wouldn't a good solution be for your windows path to have an extra 
> directory
> in it ahead of Cygwin's /bin directory, where you could put a 
> windows shortcut
> to gcc-3.exe and call it "gcc"?  That should work; by having this 
> directory at
> the front of your PATH in DOS (but not in Cygwin) you could easily 
> add
> overrides for the names of any Cygwin applications/symlinks that you 
> wanted.

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.

>  Yes, or it could just be a version difference.  I use win2k on my 
> main system.

I use WinXP Pro, SP2.

>  Something very strange is happening!  GCC doesn't read any input 
> from stdin
> in any of those cases, so it's surprising that it behaves 
> differently.

Ah!

> It might be easier than you think to change them all in one go:
> find . -name '*.bat' | xargs sed -i -e 's/gcc.exe/gcc-3.exe/g'

Thanks for the tip.

>
>  OK, hang on a moment, I know it might sound silly of me to ask but 
> now I
> have to check: you aren't doing something unusual like running 
> cmd.exe in a
> rxvt window are you?  Or do you by any chance have CYGWIN=tty set in 
> your

No.  No.

> environment variables?  I wonder if it's really "waiting for an 
> enter", or if
> it's actually waiting for a full command line, and just the prompt 
> hasn't been
> flushed to the screen yet.  What happens if you type "dir <enter>" 
> or some
> other command instead of just pressing enter on its own?

Now you got it. After doing some other test that's what i found.
Effectively if you type a command there, that command is executed.
So this is cmd.exe waiting for input (but the prompt has not
been displayed or has been erased)

>
>  In your earlier examples, where I said "Cygwin doesn't read stdin 
> anyway",
> that's still the case.  But there is one difference that might be 
> the reason
> here: when you run "gcc file.c", gcc launches a number of 
> subprocesses -
> preprocessor, compiler, assembler, linker.  With the other two 
> commands, it
> runs and exits without launching any other executables; I wonder if 
> somehow
> that means that in one case all the output gets flushed and you see 
> the prompt
> and know it's finished, in the other case the prompt gets lost in a 
> buffer
> 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.
I made some other tests. I created the shortcut from the explorer.
May be cygwin was creating the shortcut in a way that caused that 
behaviour, or may
be it was because cygwin does not use \r (just \n).
Same results.

I also tried to create a shortcut to mingw gcc.exe (which emits \r\n). 
Same results.
And i tried with a small program who does only write to stderr, and
compiled it with VisualC++ v6.0 : Same results.

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.

>  I would advise you consider my suggestion of having a
> renaming-and-overriding directory full of windows shortcuts at the 
> head of
> your PATH.  There are quite a lot of things in /bin that exist 
> primarily as
> symlinks to the real application, gcc is just one among many.

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.

>  Hey, I just tried that out to see if it works, and it does, but it 
> also
> allows me to see the "waits for enter" problem occurring!  It's 
> definitely
> just the DOS prompt getting lost somehow; any command that you type 
> before
> pressing enter does get executed when you do.  Ah, look, it's not 
> that the
> prompt is getting lost: it's just that GCC's output comes out after 
> the prompt
> for some reason.  See the example below:

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


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