<p>我怀疑不是对子窗口的写入导致getstr()返回空字符串,而是警报信号本身。(从信号处理程序中写入窗口可能也没有定义好,但这是一个单独的问题。)</p>
<p>clibrary Curses(Python的Curses模块通常构建在其之上),当任何信号(除了内部处理的少数信号外)传入时,它将从大多数阻塞输入调用中返回。在C语言中,有一个为这种情况定义的API(函数返回-1并将errno设置为EINTER)。在</p>
<p>Python模块表示,如果curses函数返回错误,它将引发异常。我不知道为什么在这种情况下它不这么做。在</p>
<p>编辑:一个可能的解决方案是使用一个比curses更适合程序员的控制台UI库。<a href="http://excess.org/urwid/" rel="nofollow">Urwid</a>出现(在我对手册的简要浏览中)以支持事件驱动的UI更新(包括对计时器的更新),同时处理键盘输入。学习这一点可能比处理信号和诅咒之间的粗略和缺乏文档记录的交互更容易。在</p>
<p>编辑:从<a href="http://linux.die.net/man/3/getch" rel="nofollow">getch()</a>的手册页:</p>
<blockquote>
<p>The behavior of getch and friends in the presence of handled signals is unspecified in the SVr4 and XSI Curses documentation. Under historical curses implementations, it varied depending on whether the operating system's implementation of handled signal receipt interrupts a read(2) call in progress or not, and also (in some implementations) depending on whether an input timeout or non-blocking mode has been set.</p>
<p>Programmers concerned about portability should be prepared for either of two cases: (a) signal receipt does not interrupt getch; (b) signal receipt interrupts getch and causes it to return ERR with errno set to EINTR. <em>Under the <strong>ncurses</strong> implementation, handled signals never interrupt <strong>getch</strong></em>.</p>
</blockquote>
<p>我尝试过使用<strong>getch</strong>而不是<strong>getstr</strong>,它确实在一个信号上返回-1。如果由<strong>getstr</strong>实现,那么(负返回值)将解决这个问题。
所以现在的选项是(1)编写自己的<strong>getstr</strong>,并进行错误处理;或者(2)使用<a href="http://excess.org/urwid/" rel="nofollow">Urwid</a>。这是Python库的bug吗?在</p>