Re: [Nano-devel] (no subject)

[David Lawrence Ramsey]

Jim's Bugs <address@hidden> wrote:

<snip>

>The problem is that rather than nano receiving a signal, in this case
>it receives EOF on stdin.  Unfortunately, nano does not seem to test
>for this possibility and ignores the key stroke, causing it to read the
>next character (still EOF) and go into an infinite loop.
>
>The solution, of course, is to test for EOF when reading from stdin. 
>Actually making a patch is, in my opinion, best left to the author(s),
>as there is no convenient way to change all the calls to wgetch to do
>the check.

Thanks for tracking this problem down.  I've looked into it.  The
ncurses manual page mentions two items dealing with this:

1. If wgetch() returns ERR in blocking mode and errno is set to EINTR,
it's been interrupted by a signal.

2. ncurses doesn't allow wgetch() to be interrupted by a signal, so
checking for errno's being EINTR won't work there, although other curses
implementations (such as OpenBSD's?) might allow it.

On my Slackware-current box, ncurses does at least returns ERR in
blocking mode when I reproduce the problem using your method, and since
ERR and EOF are both the same value (-1), it appears that checking for
ERR during blocking input accomplishes the same thing.  I've added a
patch which implements this to 1.3.5-cvs CVS, and it seems to work as
expected.  (Note that nano 1.3.x has had its input routines rewritten to
avoid having a lot of scattered wgetch() calls.)  Would you mind
checking it out and seeing whether it works for you too?  Thanks again.

>I believe fixing this bug will also fix the following two bug reports
>in Debian and Red Hat, respectively:
>
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286781
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124500

It looks that way.