Comment 1 Alain Magloire 2004-04-14 13:50:37 EDT

*** Bug 58081 has been marked as a duplicate of this bug. ***

Comment 2 Bruno Medeiros 2004-06-19 21:16:06 EDT

Hello there, my first comment :)

I have the same problem mentioned here (using Eclipse M9 and CDT M9) : any 
program I launch from Eclipse doesn't flush it's stdout. However, by any 
program I also mean MinGW and VC++ compiled executables, not just POSIX 
environment targets (such as Linux or Cygwin).

I think this questions what was said in the above description, that isatty() 
is the cause of this bug, since isatty is only for POSIX environs. Am I 
correct?
Or maybe it's another bug, but since the symptoms are exactly the same (and 
the same as bug 58081 too) that's unlikely, right?

Comment 3 Kleo Hapitas 2004-07-07 16:46:57 EDT

PR was targeted at 2.0 but was not resolved at release time. Changing target 
to 2.1

Comment 4 Alain Magloire 2004-07-16 17:51:54 EDT

*** Bug 67166 has been marked as a duplicate of this bug. ***

Comment 5 Johan Walles 2004-09-01 08:10:06 EDT

At least in theory (haven't verified this, wild speculation ahead), it should be
possible to simply do...

  setlinebuf(stdout);

... between fork() and exec() to resolve this problem.

Comment 6 Alain Magloire 2004-09-01 12:15:05 EDT

> At least in theory (haven't verified this, wild speculation ahead), it should be
> possible to simply do...

>  setlinebuf(stdout);

> ... between fork() and exec() to resolve this problem.

Well the CDT can not do that, since it does not have access to the
source code.

Comment 7 Johan Walles 2004-09-02 02:13:11 EDT

If the launcher for C / C++ programs isn't part of the CDT, who owns it? 
Platform?  SWT?

In that case, shouldn't this bug be re-assigned away from CDT to somebody that
does have (write) access to the source code?

Comment 8 Johan Walles 2004-10-21 08:18:49 EDT

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core.linux/library/exec_unix.c?rev=1.3&content-type=text/vnd.viewcvs-markup&cvsroot=Tools_Project

The function to change is exec0().  The setlinebuf(stdout) should go in right
before the following if() statement:

		if (envp[0] == NULL) {
			execv(full_path, argv);
		} else {
			execve(full_path, argv, envp);
		}

Comment 9 David Inglis 2004-10-21 09:22:52 EDT

> The function to change is exec0().  The setlinebuf(stdout) should go in right
> before the following if() statement:

I don't see how this would have any effect on the process being exec'd since
this just changes the buffering behavior of the process calling setlinebuf which
in this case is 'java'. Buffering behavior does not get inherited to other
processes through exec.  The only real solution (that I know of) would be to
create a pty setting the appropriate fd as stdin and stdout (this is pretty
simple to do on linux and solaris, but it is unclear how to make this work under
windows), or call setlinebuf in you own application code to force this behavior
that it requires.

Comment 10 Johan Walles 2004-10-28 09:02:56 EDT

David, this is the most hated CDT bug:

https://bugs.eclipse.org/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&product=CDT&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=2&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=Recent+bugs&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

If you could supply a patch (since it sounds like you've done this before), that
would be much appreciated.  Even if the patch is for *ix only, it would still be
a lot better than the current situation where it doesn't work for anybody.

Comment 11 Alain Magloire 2004-11-19 12:30:22 EST

A patch was introduced in CDT-2.1
give it a go 

Comment 12 Bruno Medeiros 2005-01-11 10:10:46 EST

Hi, I recently installed CDT 2.1 and I noticed that this bug is still there, 
or at least, that the bug I described in my first post above is still there. 
Namely: any program I launch from Eclipse running in the Console view doesn't 
flush it's stdout on newlines. It is only flushed when the program terminates 
(all at once), or when the output buffer is filled.
Running Eclipse 3.0.1 and CDT 2.1 (on Windows XP <- does the OS even matter?)

Comment 13 Johan Walles 2005-08-04 03:34:01 EDT

Alain, are there any unit tests for verifying that this stays fixed?

Some people seem to think this is (still?) broken (again?).  Personally I never
verified it, so I can't tell.

Comment 14 Alain Magloire 2005-08-04 10:40:31 EDT

(In reply to comment #13)
> Alain, are there any unit tests for verifying that this stays fixed?
> 
> Some people seem to think this is (still?) broken (again?).  Personally I never
> verified it, so I can't tell.
> 

It is not easy to "fix" and it depends on the OS.

The line buffering policy for the stdio or for C++ iostream, is base on whether
or not the output stream maps to a real console or a pty for Linux user.

On Linux, we find a way to do this by creating a pseudo pty, this will
work for debug launch and normal launch(in most of the case).

On Windows, for the GDB backend we create a command console that is
associated with the application, this will work for debug launch.

On Windows for normal launch we have no solution, so the output will not
be line buffered.  So yes this is still a problem for windows.

This bug was flip to fix because it was targetting Linux(Unix-All) and
a solution was provided.

The other comments are for windows and folks should make a new PR for it.

Comment 15 Alain Magloire 2005-08-04 11:42:31 EDT

> The other comments are for windows and folks should make a new PR for it.

Ok, I found the right PR:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=102043

This is the PR for the Windows launch buffering.

For you info, your idea about setLineBuffer() is not practical
since the fork()/exec() is not possible since the buffering policy
are not transfer across processes.

The other idea, is to explore on how to make a terminal for windows.