Re: c++filt causing flashing console windows

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > Andrew Haley wrote:
 > > Øyvind Harboe writes:
 > >  > > > -Dgnu.gcj.runtime.NameFinder.demangle=false
 > >  > > > -Dgnu.gcj.runtime.NameFinder.use_addr2line=false
 > >  > >
 > >  > >Surely the bug is not here.  exec'ing c++filt and addr2line 
 > >  > >should not cause anything to flash, and that is the bug.
 > >  > 
 > >  > Flashing isn't a very accurate technical term, I guess. :-)
 > >  > 
 > >  > When a GCJ application compiled with w/-mwindows
 > >  > launches a console application (e.g. addr2line), a console
 > >  > window is created for that application.
 > > 
 > > But addr2line isn't a console application; it simply writes to stdout.
 > 
 > It is - and so is c++filt. The "console" part refers not to a GUI
 > console but to something more like a dumb TTY.

In which case, why is a window created?  Runtime.exec() starts a
process with its stdin, stdout, and stderr attached to the parent
process.  In this case, there is no way that the "console" can be used
to do I/O.

 > The "console" is what gives the application the standard stdout,
 > stderr and stdin streams. If an application does not use these
 > streams and gets its input from elsewhere (GUI events), then it can
 > be compiled with "-mwindows" (on MinGW) to omit the Command Prompt
 > window that would be shown otherwise.
 > 
 > If a GUI application spawns a console application, Windows will
 > launch the application with an attached console (a Command Prompt
 > window).

But that makes no sense in the context of Runtime.exec(), which
creates an instance of Process.  The Java spec says:

"The created subprocess does not have its own terminal or console."

How much clearer can it be?

Andrew.