At 10:50 AM 1/12/2002 +1100, Robert Collins wrote:
Have you tried the latest snapshot and confirmed that this still occurs?
Yes, this is with the latest snapshot. I actually haven't upgraded past
1.3.2 because the problems (like this) get worse from then on (using bash
as /bin/sh being the
Chris Faylor wrote:
There is a snapshot up there now which seems to work ok.
Again, many thanks to Robert Collins for tracking this down.
Although I said I wasn't overly interested in tracking this down
myself, I was interested in seeing the lessening in email traffic that I
hope this fix
- Original Message -
From: Andy Piper [EMAIL PROTECTED]
Many thanks for looking at this. While the iron is hot - this problem
is
still outstanding and I don't know whether you would expect this to be
fixed also:
Can I suggest you start a new thread when the topic changes, it helps
At 11:11 PM 1/11/2002 +1100, Robert Collins wrote:
Start the ash script in the background, and then use ps. See if the java
program appears in ps. If it does - check via task manager or process
explorer to see if the reported cygwin pid is the same as the actual
java.exe pid.
If it doesn't
At 01:22 AM 1/12/2002 +1100, Robert Collins wrote:
- Original Message -
From: Andy Piper [EMAIL PROTECTED]
ash script pid reported by shell: 828
ash script pid in task manager: 856
java pid reported by ps 1640PPID 828
java pid reported by task
- Original Message -
From: Andy Piper [EMAIL PROTECTED]
Its a console app that happily responds to ^C. If you run it directly
from
within bash then ^C works, so I assume from what you say above that
this is
a bug of some description.
Have you tried the latest snapshot and confirmed
On Thu, Jan 10, 2002 at 06:59:54PM +1100, Robert Collins wrote:
I was going back over this thread before checking in a change to see if
I'd missed something.
I just realized that I didn't address this concern. Don't know if it
matters but...
The difference between the SIG_IGN way and the
On Wed, Jan 09, 2002 at 12:16:04PM +1100, Robert Collins wrote:
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
I'm specifically trying not to do the TRUE thing, though, since
AFAICT it isn't always appropriate.
If you want to SIG_IGN the signal, then it is: When a CTRL+C
There is a snapshot up there now which seems to work ok.
Again, many thanks to Robert Collins for tracking this down.
Although I said I wasn't overly interested in tracking this down
myself, I was interested in seeing the lessening in email traffic that I
hope this fix engenders.
I do expect
On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote:
FWIW this patch (Chris where should I put the in_stub declaration)
There is already an indicator that an execed process is running --
hExeced, so I don't think you need the 'in_stub' thing.
However, it seems to me that this
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
On Tue, Jan 08, 2002 at 06:00:16PM +1100, Robert Collins wrote:
FWIW this patch (Chris where should I put the in_stub declaration)
There is already an indicator that an execed process is running --
hExeced, so I don't
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
* The new process must not have signalled it's creation back to us.
I don't think this is right, actually. You basically don't want the
stub
to *ever* send a CTRL-C in your scenario. I don't see why it matters
that
the
On Wed, Jan 09, 2002 at 11:43:41AM +1100, Robert Collins wrote:
I have to think about the race issues here. It seems like you can't
get away without some kind of additional communication between the
parent and the child.
True. The problem is that we can't communicate with non-cygwin
children.
===
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
So, I think the easiest fix for the current problem is just to do a
'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess, restoring
the previous signal handler if the CreateProcess fails.
You do realise, that
On Wed, Jan 09, 2002 at 11:57:04AM +1100, Robert Collins wrote:
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
So, I think the easiest fix for the current problem is just to do a
'signal (SIGINT, SIG_IGN)' prior to calling CreateProcess, restoring
the previous signal
Hi Christopher,
Here's the harsh reality: it is extremely unlikely that anyone is going
to investigate this. If you are using non-cygwin apps with bash and
CTRL-C doesn't work then you are on your own.
OK.
I will enthusiastically inspect and evaluate any fixes that you provide
to cygwin
On Mon, 2002-01-07 at 19:47, Michael Rumpf wrote:
The problem is that the signal handling of the bash is not working correctly
in the C/C++ app which forks others.
I'm not clear: Is the app that forks others a Cygwin app, or not?
ie: as a process chain is it
bash (cygwin)
app1 (cygwin)
app2
Hi Robert,
On Mon, 2002-01-07 at 19:47, Michael Rumpf wrote:
The problem is that the signal handling of the bash is not working
correctly
in the C/C++ app which forks others.
I'm not clear: Is the app that forks others a Cygwin app, or not?
ie: as a process chain is it
bash (cygwin)
- Original Message -
From: Michael Rumpf [EMAIL PROTECTED]
Yes, that is what I meant.
bash (cygwin, of course)
app1 = signals (MS CRT)
app2 = myclass.exe (MS CRT) or java myclass (???)
Lets leave java to the side. If we solve it with MS CRT, and java apps
still have problems, then
- Original Message -
From: Michael Rumpf
To:
Sent: Thursday, December 20, 2001 10:11 AM
Subject: Re: bash/cmd CTRL-C problem...
Hi,
sorry for following up myself, but I found out that Cygwin equally handles
CTRL-BREAK and CTRL-C by sending a SIGINT to the process
... ??
Nah, this is the right list. Nobody has an answer, though.
Did you try `CYGWIN=... tty ...' setting?
Corinna
Michael
- Original Message -
From: Michael Rumpf
To:
Sent: Thursday, December 20, 2001 10:11 AM
Subject: Re: bash/cmd CTRL-C problem
Michael
- Original Message -
From: Michael Rumpf
To:
Sent: Thursday, December 20, 2001 10:11 AM
Subject: Re: bash/cmd CTRL-C problem...
Hi,
sorry for following up myself, but I found out that Cygwin equally
handles
CTRL-BREAK
For the record, here is a very simple java test program that I sent to
Troy when
we discussed this problem last November. This program simply intercepts
CTL-C
and runs a shutdown hook prior to shutting down the Java VM. It works fine
under
cmd.exe and cygwin ash, but does not work under
(I just returned from vacation so excuse me for responding to an old
message but I really feel compelled to respond to this one...)
Christopher,
This reply puzzles me. What is the point of cygwin if not to support
interoperability between win32 and unix environments? If all I wanted
was an
On Mon, Jan 07, 2002 at 12:08:51PM -0500, Gregory W. Bond wrote:
I agree that this behavior should be considered a bug since the bash
cygwin behavior differs from bash behavior on other unix platforms.
This has caused headaches for our project too.
Hmm. How does bash on other unix platforms
On Mon, Jan 07, 2002 at 12:30:33PM -0500, Gregory W. Bond wrote:
(I just returned from vacation so excuse me for responding to an old
message but I really feel compelled to respond to this one...)
Why did you Cc me when I specifically set the Reply-To to
[EMAIL PROTECTED] and am obviously
Christopher,
I addressed my message to you out of politeness since it was intended for you. I
addressed the message to cygwin since I thought it might also be of interest to the
readers of the mailing list. It's not an unusual convention to follow on mailing
lists, however, I won't do this with
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
It succeeds! (I'm running a slightly modified cygwin here, which as
the
patch at the end of this email shows (in combination with the source
:})
should always indicate if there is an error).
It should always succeed. A
On Tue, Jan 08, 2002 at 10:00:33AM +1100, Robert Collins wrote:
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
It succeeds! (I'm running a slightly modified cygwin here, which as
the
patch at the end of this email shows (in combination with the source
:})
should always
On Tue, Jan 08, 2002 at 11:15:11AM +1100, Robert Collins wrote:
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
If you are looking for the stub code, it's in spawn_guts, around
line
1078 in the current sources.
Line 1078 is the EOF for spawn.cc (current CVS). Is that
===
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 08, 2002 11:21 AM
Subject: Re: CGF: please review my logic Re: bash/cmd CTRL-C problem...
On Tue, Jan 08, 2002 at 11:15:11AM +1100, Robert Collins wrote:
- Original
FWIW this patch (Chris where should I put the in_stub declaration)
Index: exceptions.cc
===
RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v
retrieving revision 1.103
diff -u -p -r1.103 exceptions.cc
--- exceptions.cc
On Fri, Jan 04, 2002 at 12:52:43PM +0100, Michael Rumpf wrote:
I further investigated the bash CTRL-C problem and found out that pressing
CTRL-C in the bash is nearly the same as CTRL-BREAK. I tried all the
CYGWIN=tty/notty/empty combinations but that did not change anything...
[snip]
The cmd
?
Corinna
Michael
- Original Message -
From: Michael Rumpf [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 20, 2001 10:11 AM
Subject: Re: bash/cmd CTRL-C problem...
Hi,
sorry for following up myself, but I found out that Cygwin equally handles
CTRL-BREAK
shell and bash under Linux ,
HP-UX 10/11, AIX4.x, and SunOS 2.5+...
Please help, I don't want to use the stupid windows cmd shell ;-)
Michael
- Original Message -
From: Michael Rumpf [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 20, 2001 7:47 AM
Subject: bash/cmd CTRL
Hi,
I'm new to the list and I don't know if this problem is already solved, but
I couldn't find a hint neither on the archives nor on the FAQ or somewhere
else on the net.
My problem is related to bash/cmd and signal handling.
In my app I installed a signal handler for SIGINT. The app is going
36 matches
Mail list logo
