Here is a sample program which does the right thing (no spurious console
windows, all output visible) when run either from a console or from a
console-free environment, such as a Cygwin xterm. This is the code
we'll be working into libiberty -- unless someone has a better solution!
The potential
On 14 March 2006 18:52, Ross Ridge wrote:
Here is a sample program which does the right thing (no spurious console
windows, all output visible) when run either from a console or from a
console-free environment, such as a Cygwin xterm. This is the code
we'll be working into libiberty --
Is this really worth it? Could this whole problem be solved by you
switching to rxvt? Maybe the only problem is that your xterm is broken.
Nothing is broken. The problem is that Cygwin applications run in a
slightly special environment, where there may not be a console attached to
the
On 14 March 2006 19:22, Paul Brook wrote:
Is this really worth it? Could this whole problem be solved by you
switching to rxvt? Maybe the only problem is that your xterm is broken.
Nothing is broken. The problem is that Cygwin applications run in a
slightly special environment, where
Dave Korn writes:
I don't understand why you think Mark's code needs to search the PATH or
append '.exe', when it invokes CreateProcess that does all that for you?
I've already answered that question: subtle differences in the other
behaviours could cause problems. The search behaviour and
On Tuesday 14 March 2006 19:46, Ross Ridge wrote:
Dave Korn writes:
I don't understand why you think Mark's code needs to search the PATH or
append '.exe', when it invokes CreateProcess that does all that for you?
I've already answered that question: subtle differences in the other
Ross Ridge wrote:
Arguably, not having a console window attached a shell window is broken
in the Cygwin environment.
Paul Brook wrote:
How exactly do you suggest implementing this?
The same way Cygwin rxvt implements this.
By implication you're saying that you shouldn't able to use gcc
On Sun, Mar 12, 2006 at 09:16:47PM -0800, Mark Mitchell wrote:
Christopher Faylor wrote:
I don't see any reason why cygwin should be causing a console window to
flash when spawn is used.
Maybe this is something that should be pursued in the Cygwin list. The
test cases will be useful but
On Sun, Mar 12, 2006 at 09:43:12PM -0800, Mark Mitchell wrote:
Mark Mitchell wrote:
What cygcheck output would be helpful? I've never run cygcheck until
just now, and it seems to have lots of options.
By the way, I don't see any reason to suspect that there's a Cygwin bug.
The situation is:
Christopher Faylor wrote:
ptys are supposed to have invisible consoles associated with them. Since
xterm uses an invisible console I still don't see why there should be
a console popup.
This still sounds like a cygwin problem to me.
As a test case, I'd recommend the latest code I posted.
Mark Mitchell wrote:
As a test case, I'd recommend the latest code I posted. If a MinGW
application tries to open CONOUT$ with CreateFile, it gets
INVALID_HANDLE_VALUE, so the OS doesn't seem to think the console is
available.
I should have said in a Cygwin xterm somewhere in that
On Tue, Mar 14, 2006 at 04:56:21PM -0800, Mark Mitchell wrote:
Mark Mitchell wrote:
As a test case, I'd recommend the latest code I posted. If a MinGW
application tries to open CONOUT$ with CreateFile, it gets
INVALID_HANDLE_VALUE, so the OS doesn't seem to think the console is
available.
I
Christopher Faylor wrote:
And, if it can't open CONOUT$ in cygwin's xterm, that's a bug...
Great!
But that's also irrelevant to the broader issue as to whether or not we
try to get this right in libiberty. The issue isn't Cygwin; the issue
is whether or not we operate correctly when gcc is
Here is a sample program which does the right thing (no spurious console
windows, all output visible) when run either from a console or from a
console-free environment, such as a Cygwin xterm. This is the code
we'll be working into libiberty -- unless someone has a better solution!
--
Mark
Mark Mitchell wrote at http://gcc.gnu.org/ml/gcc/2006-03/msg00441.html
Here is a sample program which does the right thing (no spurious
console
windows, all output visible) when run either from a console or from
Danny Smith wrote:
In my experience, following test is not necessary. Win9x just ignores
the CREATE_NO_WINDOWS flag so setting it is a harmless no-op on these
platforms.
It's OK with me not to do it; I just didn't have those platforms to use
for testing, and it seems more pedantically
Mark Mitchell wrote:
Cygwin Xterm
parent spawn: Pops up DOS window.
parent nostd: No output from child.
parent std: Works.
DOS Console
===
parent spawn: Works.
parent nostd: No output from child.
parent std: No output from child.
This is what I got using your code and
Ross Ridge wrote:
Cygwin rxvt
===
parent spawn: Works.
parent nostd: No output from child.
parent std: Works.
I wasn't able to test it with xterm, I don't have an X server handy,
but it looks your problem is with xterm, not gcc.
CodeSoucery's 3.4-based code worked in all
On Sun, Mar 12, 2006 at 03:27:02PM -0500, Ross Ridge wrote:
Mark Mitchell wrote:
Cygwin Xterm
parent spawn: Pops up DOS window.
parent nostd: No output from child.
parent std: Works.
DOS Console
===
parent spawn: Works.
parent nostd: No output from child.
parent std: No
Christopher Faylor wrote:
I don't see any reason why cygwin should be causing a console window to
flash when spawn is used.
Maybe this is something that should be pursued in the Cygwin list. The
test cases will be useful but please also provide cygcheck output - as
an attachment, please.
Mark Mitchell wrote:
What cygcheck output would be helpful? I've never run cygcheck until
just now, and it seems to have lots of options.
By the way, I don't see any reason to suspect that there's a Cygwin bug.
The situation is:
1. A Cygwin xterm does not have an associated console.
2. You
I'll happily test a patch to that file for you...the only box at my
house runs Windows... =-O
Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
The new pex-win32.c code doesn't operate correctly when used for
MinGW-hosted tools invoked from a Cygwin window. In particular,
Mark Mitchell wrote:
The new pex-win32.c code doesn't operate correctly when used for
MinGW-hosted tools invoked from a Cygwin window. In particular, process
creation (gcc invoking as, say) results in a DOS console window
popping up. When invoked from a DOS window, things are fine.
What sort of
Ross Ridge wrote:
Mark Mitchell wrote:
The new pex-win32.c code doesn't operate correctly when used for
MinGW-hosted tools invoked from a Cygwin window. In particular, process
creation (gcc invoking as, say) results in a DOS console window
popping up. When invoked from a DOS window, things
Ross Ridge wrote:
I think you're barking up the wrong tree here. Windows only creates
console windows automagically when a console application starts that
can't inherit its parent's console window.
Mark Mitchell wrote:
Exactly -- there is no parent console window here.
Why isn't there a
Ross Ridge wrote:
Why isn't there a console window? The Cygwin version of rxvt, and I
think xterm, creates (and keeps hidden) a console window that should
be inherited by gcc and as. If there wasn't console window for gcc to
inherit, why didn't Windows create one for gcc?
I can't answer
Ian --
The new pex-win32.c code doesn't operate correctly when used for
MinGW-hosted tools invoked from a Cygwin window. In particular, process
creation (gcc invoking as, say) results in a DOS console window
popping up. When invoked from a DOS window, things are fine.
The reason for this
Mark Mitchell [EMAIL PROTECTED] writes:
The new pex-win32.c code doesn't operate correctly when used for
MinGW-hosted tools invoked from a Cygwin window. In particular, process
creation (gcc invoking as, say) results in a DOS console window
popping up. When invoked from a DOS window, things
28 matches
Mail list logo
