public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Control-c of a bat file does not kill commands run by bat file in some cases
@ 2008-07-18 16:46 Mark Charney
  2008-07-18 17:13 ` Corinna Vinschen
  2008-07-18 19:50 ` Hugh Sasse
  0 siblings, 2 replies; 4+ messages in thread
From: Mark Charney @ 2008-07-18 16:46 UTC (permalink / raw)
  To: cygwin

Is this a bug or a feature?

When I run a program loop.exe   whose entire source is "int main() {   while(1);  return 0;}", compiled with MS VS8 or cygwin's gcc, from a bat file whose contents are just "loop.exe" and hit control-c while it is running, sometimes cygwin kills the loop.exe and sometimes it does not. Here are the 6 scenarios that I tried:

1. OKAY tcsh  from a cmd.exe 
2. OKAY bash from a cmd.exe 
3. BROKEN tcsh from an rxvt X window  on local machine
4. BROKEN bash from an rxvt X window on local machine
5. BROKEN tcsh via ssh from a remote machine  (public key auth)
6. BROKEN bash via ssh from a remote machine (public key auth)

OKAY means it kills the bat file and loop.exe
BROKEN means loop.exe continues to run after control-c.

bash/tcsh doesn't not seem to matter, I just did it because I first noticed the problem on tcsh.

At the very least, if it is a feature, it is inconsistent.

My cygwin installation is relatively up to date. This has been a problem for a long time and I'm just getting around to characterizing it. If you want a cygcheck output, or other information please let me know. My cygwin is 1.5.25-15.  If you want a C program instead of a bat file, I think we can do that.


      

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Control-c of a bat file does not kill commands run by bat file  in some cases
  2008-07-18 16:46 Control-c of a bat file does not kill commands run by bat file in some cases Mark Charney
@ 2008-07-18 17:13 ` Corinna Vinschen
  2008-07-18 19:50 ` Hugh Sasse
  1 sibling, 0 replies; 4+ messages in thread
From: Corinna Vinschen @ 2008-07-18 17:13 UTC (permalink / raw)
  To: cygwin

On Jul 18 09:45, Mark Charney wrote:
> Is this a bug or a feature?
> 
> When I run a program loop.exe   whose entire source is "int main() {   while(1);  return 0;}", compiled with MS VS8 or cygwin's gcc, from a bat file whose contents are just "loop.exe" and hit control-c while it is running, sometimes cygwin kills the loop.exe and sometimes it does not. Here are the 6 scenarios that I tried:
> 
> 1. OKAY tcsh  from a cmd.exe 
> 2. OKAY bash from a cmd.exe 
> 3. BROKEN tcsh from an rxvt X window  on local machine
> 4. BROKEN bash from an rxvt X window on local machine
> 5. BROKEN tcsh via ssh from a remote machine  (public key auth)
> 6. BROKEN bash via ssh from a remote machine (public key auth)
> 
> OKAY means it kills the bat file and loop.exe
> BROKEN means loop.exe continues to run after control-c.
> 
> bash/tcsh doesn't not seem to matter, I just did it because I first noticed the problem on tcsh.
> 
> At the very least, if it is a feature, it is inconsistent.

What do you expect?  In cases 3 to 6 you're running a VC++ console
application in a Cygwin pseudo tty session, not in a Windows console.
Native Windows apps have no idea what a Cygwin signal (in this case
SIGINT) is, so it doesn't handle it.  And, since you don't have a
Windows console, you don't get Windows console "signal" handling which
would inject a thread into the application which by default stops the
application on Ctrl-C.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Control-c of a bat file does not kill commands run by bat file  in some cases
  2008-07-18 16:46 Control-c of a bat file does not kill commands run by bat file in some cases Mark Charney
  2008-07-18 17:13 ` Corinna Vinschen
@ 2008-07-18 19:50 ` Hugh Sasse
  2008-07-19  0:05   ` Brian Dessent
  1 sibling, 1 reply; 4+ messages in thread
From: Hugh Sasse @ 2008-07-18 19:50 UTC (permalink / raw)
  To: Mark Charney; +Cc: cygwin

On Fri, 18 Jul 2008, Mark Charney wrote:

> Is this a bug or a feature?
>
> When I run a program loop.exe   whose entire source is "int main()
> {   while(1);  return 0;}", compiled with MS VS8 or cygwin's gcc,
> from a bat file whose contents are just "loop.exe" and hit
> control-c while it is running, sometimes cygwin kills the loop.exe
> and sometimes it does not. Here are the 6 scenarios that I tried:
>
> 1. OKAY tcsh  from a cmd.exe
> 2. OKAY bash from a cmd.exe
> 3. BROKEN tcsh from an rxvt X window  on local machine
> 4. BROKEN bash from an rxvt X window on local machine
> 5. BROKEN tcsh via ssh from a remote machine  (public key auth)
> 6. BROKEN bash via ssh from a remote machine (public key auth)
>
> OKAY means it kills the bat file and loop.exe
> BROKEN means loop.exe continues to run after control-c.
>
> bash/tcsh doesn't not seem to matter, I just did it because I first noticed the problem on tcsh.

Agreed.

The thing that is varying, it seems to me, is your perceived
terminal type.  I mean as perceived by the system.  Try the
3 ways of connecting {cmd, rxvt, ssh} against 
stty -a
echo $TERM
to see what these things are.  I think stty -a should suffice
to tell you what "intr" is.  Or, in other words, you may have
to hit something other than <ctrl-C> to kill things, unless you
reset it with stty.

         HTH
         Hugh


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Control-c of a bat file does not kill commands run by bat file  in   some cases
  2008-07-18 19:50 ` Hugh Sasse
@ 2008-07-19  0:05   ` Brian Dessent
  0 siblings, 0 replies; 4+ messages in thread
From: Brian Dessent @ 2008-07-19  0:05 UTC (permalink / raw)
  To: cygwin

Hugh Sasse wrote:

> to see what these things are.  I think stty -a should suffice
> to tell you what "intr" is.  Or, in other words, you may have
> to hit something other than <ctrl-C> to kill things, unless you
> reset it with stty.

That logic is faulty because stty is a Cygwin program.  When connected
to a pty it will therefore correctly know how to interpret and output
the settings of the slave end of the pty.  And Cygwin programs when run
in a pty will correctly respond to SIGINT.  The problem is that you're
not talking about a Cygwin program, you're talking about a native win32
program which has no concept of what a pty is and just thinks its
running as a detached process with no console and a pipe for stdin.  Or
in other words, it's irrelevant what stty reports that "intr" is set to,
correct or not, because that only applies to pty-aware apps.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-07-19  0:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-18 16:46 Control-c of a bat file does not kill commands run by bat file in some cases Mark Charney
2008-07-18 17:13 ` Corinna Vinschen
2008-07-18 19:50 ` Hugh Sasse
2008-07-19  0:05   ` Brian Dessent

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).