Chet Ramey wrote:
> Joe Peterson wrote:
>
>> Well, without a hacked kernel, you'll probably not hit
>> *this* manifestation of the issue, but what I did was:
>>
>> - run a text processing program (like "cat" or "tr")
>> - hit ctrl-S
>> - enter lots of text that will then produce lots of output
>> - hold down ctrl-C until the error is produced
>>
>> Fix:
>> Should interrupts be trapped during call to tcsetattr()?
>
> I don't think so. Readline already blocks interrupts when it calls
> tcsetattr, and bash handles that call returning -1/EINTR appropriately.
Hi,
Yep, I see the code that returns -1 in jobs.c:
---------
if (tcgetattr (tty, &shell_tty_info) < 0)
{
#if 0
/* Only print an error message if we're really interactive at
this time. */
if (interactive)
sys_error ("[%ld: %d] tcgetattr", (long)getpid (), shell_level);
#endif
return -1;
}
---------
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.
Thanks, Joe
