[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: "tcsetattr: Interrupted system call" after rapid-fire ^C chars
From:       Chet Ramey <chet.ramey () case ! edu>
Date:       2008-10-15 18:06:44
Message-ID: 081015180644.AA90020.SM () caleb ! INS ! CWRU ! Edu
[Download RAW message or body]

> And that sys_error message is, I believe, the exact error I am seeing.
> What I am wondering is how did I manage to invoke this by using ^C?  Did
> I hit some small window when readline was not running and when the
> program that would normally catch the kill signal was not listening
> (i.e. bash itself somehow caught it)?  I did not think this was
> possible.  Just wondering if this is something that should not happen.

The window's certainly there when the child exits and bash reaps it.  Once
the child dies and the terminal's foreground process group gets reset to
bash's, the shell will receive the SIGINTs generated by repeated ^C.  Bash
installs a signal handler for SIGINT, but the SIGINT will still interrupt
tcsetattr, especially if tcsetattr is called with TCSADRAIN.  (The code in
question is ensuring that a process that exits due to a signal won't leave
the terminal in an unusable state.  It's just one of the housekeeping things
that happens before readline is called to read the next command.)

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://tiswww.tis.case.edu/~chet/



[prev in list] [next in list] [prev in thread] [next in thread]