Missing reset of signal handlers

[GoogleCodeExporter]

::::What steps will reproduce the problem?
1. Run 'make' or some shell script that does a fair amount of work
2. Try to hit Ctrl+C
3. Nothing happens

::::What is the expected output? What do you see instead?
I expect the make process to interrupt; instead, nothing happens.  The
behaviour works as expected in rxvt.

For example, building in a certain directory in my codebase in MinTTY, I
see (I am hitting Ctrl+C throughout this entire process):
$ make
Building subdir: comm...
Building subdir: comm/cmt...
Building subdir: comm/db...
Building subdir: comm/xml...
Building subdir: comm/binary...
Building subdir: queries...
Building subdir: records...
Building subdir: requests...
Building subdir: tables...

Doing the same in rxvt:
$ make
Building subdir: comm...
Building subdir: comm/cmt...
make: *** [comm] Interrupt

::::What version of the product are you using? On what operating system?
Windows XP, mintty 0.4-beta1

Original issue reported on code.google.com by twilla...@gmail.com on 16 Apr 2009 at 3:35

[GoogleCodeExporter]

Something I've found out that's interesting - Ctrl+C works as expected if run 
within
mintty+screen, but if I'm in bash (no screen), the behaviour is the same as 
above.

$ make
Building subdir: comm...
Building subdir: comm/cmt...
make: *** [comm] Interrupt

I've updated to mintty 0.4-beta2, and the issue persists.

Original comment by twilla...@gmail.com on 16 Apr 2009 at 6:16

[GoogleCodeExporter]

mintty simply sends the ^C character when you press Ctrl+C, and it's up to the
terminal driver to translate that into a SIGINT. Have a look at the output of 
"stty
-a", where it should say "intr = ^C".

A couple of other suggestions:
- compare the whole "stty -a" output in mintty and rxvt
- try reproducing the issue in xterm

Original comment by andy.koppe on 21 Apr 2009 at 4:18

[GoogleCodeExporter]

I've tried comparing the stty -a output between mintty and rxvt.  The 
differences are:

$ diff  stty.mintty stty.rxvt
16c16
< swtch=^Z
---
> swtch=<undef>
23c23
< flush=<undef>
---
> flush=^O
36c36
< -ignpar
---
> ignpar
47c47
< -imaxbel
---
> imaxbel
66,67c66,67
< -echoe
< -echok
---
> echoe
> echok
71,72c71,72
< -echoctl
< -echoke
---
> echoctl
> echoke

I attempted applying all of rxvt's stty settings in mintty, and the issue 
persists.

An easier way to see it is to run

$ grep "Hi"

and try to cancel it with Ctrl+C - I can in rxvt (or in mintty+screen), but I 
can't
in mintty - even with identical stty settings to rxvt.

I'll try to muck around with it in xterm, but I'm having troubles getting xterm 
to
launch on my work machine (with or without X running)

Original comment by twilla...@gmail.com on 21 Apr 2009 at 5:43

[GoogleCodeExporter]

I got xterm to run (didn't have uptodate dependencies - oops).

Differences in the stty are about the same:

$ diff stty.mintty stty.xterm
11c11
< erase=^?
---
> erase=^H
23c23
< flush=<undef>
---
> flush=^O
66,67c66,67
< -echoe
< -echok
---
> echoe
> echok
71,72c71,72
< -echoctl
< -echoke
---
> echoctl
> echoke

xterm behaves exactly like rxvt - Ctrl+C works fine to cancel the grep command.

Original comment by twilla...@gmail.com on 21 Apr 2009 at 5:51

[GoogleCodeExporter]

How are you invoking mintty? Any chance you're running different executables in
mintty, i.e. non-Cygwin ones e.g. from MSYS or UnixUtils?

Original comment by andy.koppe on 21 Apr 2009 at 6:03

[GoogleCodeExporter]

Good call on the invocation - something's wierd here. I'm invoking Mintty 
through a
quick-launch icon linked to this script:

----------------
#!/bin/bash
export PATH="$PATH:/c/Programs/cygwin/bin"
DISPLAY=:0
mintty --title $COMPUTERNAME -e bash -l -i &
----------------

If I remove the ampersand at the end of the mintty command line, the issue goes 
away,
however I'm left with a secondary terminal window in the background all the time
(hence why I launched mintty in the background to begin with - gets rid of the
terminal window).

If I switch my mintty command in that script for an identical rxvt command 
(with or
without the ampersand), there's no background terminal stuck open, and I can 
ctrl+C
to my heart's content:

----------------
#!/bin/bash
export PATH="$PATH:/c/Programs/cygwin/bin"
DISPLAY=:0
#mintty --title $COMPUTERNAME -e bash -l -i
rxvt -d :0 --title $COMPUTERNAME -e bash -l -i &
----------------

Any idea why backgrounding mintty from the script causes this issue, or why 
_not_
backgrounding mintty leaves me with a terminal open? 

Original comment by twilla...@gmail.com on 21 Apr 2009 at 6:20

[GoogleCodeExporter]

In the meantime, I've changed my desktop shortcut to point directly to mintty 
(and
modified my .bash_profile to get those other variables set) - this essentially 
fixes
my problem for the time being.

Original comment by twilla...@gmail.com on 21 Apr 2009 at 6:25

[GoogleCodeExporter]

rxvt contains some magic to detach itself from its parent process. MinTTY 
doesn't, so
not backgrounding it keeps the bash script running and its console open. I 
don't know
what happened with the backgrounding. 

I'd certainly recommend invoking mintty directly though. If you don't want to 
add
those variables to your startup scripts, you can add them to the shortcut like 
so:

mintty "/bin/sh DISPLAY=:0 /bin/bash -li"

(The "/bin/"s can be omitted if the "Start in" field of the shortcut is set to 
the
Cygwin bin directory.)

Original comment by andy.koppe on 21 Apr 2009 at 6:54

• Changed state: Invalid

[GoogleCodeExporter]

Apologies for using up your time on an invalid ticket - but thanks for your 
help. :)

I'm basically indifferent where those variables get set and how I invoke mintty.

The only reason I was using the bash script to launch rxvt was because it was
basically the "company standard" setup; when I switched from rxvt to mintty all 
I did
was edit the script provided by the higher-ups.  

Original comment by twilla...@gmail.com on 21 Apr 2009 at 7:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I also had this issue when I was starting mintty from within a bash script.  
With the 
help of google, I found a solution to my problem, which I'm sharing here for 
the 
benefit of others.

I had a bash script called "nterm" which is run as eg. "nterm my task name" to 
create 
a fresh terminal window with the heading "my task name".  (It inherits 
environment 
and current directory from the calling shell, and fits better with my workflow 
than 
creating a new window from the gui.)  With mintty I experienced the problem 
with 
ctrl-c not working as I expected.  I replaced the script with the following 
bash 
function, defined in my .bashrc:
function nterm() { mintty -t "$*" & }

mintty windows created with this function behaved as I expected - ctrl-c works 
to 
break out of programs.
For those who (like me) aren't that familiar with bash functions, this can be 
invoked 
from the bash command-line exactly as my script was: "nterm my task name"

(My apologies to anyone who received notifications of my multiple edits.)

Original comment by barry.do...@gmail.com on 27 May 2009 at 9:58

[GoogleCodeExporter]

Hmm, I don't know why invoking it from a bash function rather than a bash script
should make a difference to this. Could you attach your original script to try?

Original comment by andy.koppe on 27 May 2009 at 6:36

• Changed state: New

[GoogleCodeExporter]

I think I deleted my only copy, but I recreated a copy from memory that shows 
the 
same characteristics.  Only 2 lines, so here it is:
#!/bin/bash -e
mintty -t "$*" - &

Original comment by barry.do...@gmail.com on 3 Jun 2009 at 3:09

[GoogleCodeExporter]

Reproduced. This one-liner shows the same problem:

bash -c "mintty&"

This is really weird. No difference in 'stty -a' output. Ctrl-Z does work, while
Ctrl-C and Ctrl-\ don't. The characters are being sent to the pty alright, but 
for
some reason they aren't translated to signals. Works fine with rxvt and xterm.

Original comment by andy.koppe on 13 Jul 2009 at 4:59

• Changed state: Accepted
• Added labels: Priority-Medium

[GoogleCodeExporter]

Turns out this isn't all that weird. MinTTY inherits its signal handler 
settings from
its parent process and simply passes them on to the child, and it would appear 
that
bash blocks SIGINT and SIGQUIT for processes invoked from a script with &.

Xterm and rxvt set a number of signals to SIG_DFL or SIG_IGN in the child 
process, so
MinTTY has to do the same. Fixed in r428 on 0.4 branch.

Original comment by andy.koppe on 13 Jul 2009 at 6:21

• Changed title: Missing reset of signal handlers
• Changed state: Fixed
• Added labels: Difficulty-Easy, Milestone-0.4.4

[GoogleCodeExporter]

Original comment by andy.koppe on 18 Jul 2009 at 12:15

• Changed state: Verified