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 ru
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.
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 sen
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 poste
On Tue, Mar 14, 2006 at 07:59:22PM +, Paul Brook wrote:
>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 al
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 situat
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 us
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 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
> b
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 ex
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 environ
> > 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
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 -
>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 potent
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 corr
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
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 Mitch
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. Yo
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, ple
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
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
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 c
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
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:
> 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 win
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
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 <[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 windo
28 matches
Mail list logo
