Bug#556846: libcurses-ui-perl: Solaris-specific hack breaks expected behaviour (at least on Linux)
I have a reasonably large application that uses Curses::UI and
Curses::UI::POE. When keyboard input is buffered because the app is blocking,
things get out of sync when the app returns - keys get "lost" and the app is
thereafter "one key behind".
The problem was eventually narrowed down to the following part of
# See if there are pending keys on input. If I do not
# feed them to the application in this way, the screen
# hangs in case I do a lot of input on my Solaris
$key = $self->get_key(0);
$self->feedkey($key) unless $key eq '-1';
This is something of a hack. On my Linux machine, commenting out the above
causes correct behaviour, whereby keypresses are buffered and dealt with when
the app returns from its blocking behaviour.
I'm raising this bug as I'd like to implement the patch in Debian, but would
welcome input from other members of the Debian Perl team. I will raise the
issue upstream as well.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-bpo.2-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libcurses-ui-perl depends on:
ii libcurses-perl 1.23-1+b1 Curses interface for Perl
ii libterm-readkey-perl 2.30-4 A perl module for simple terminal
ii perl 5.10.0-19lenny2 Larry Wall's Practical Extraction
libcurses-ui-perl recommends no packages.
libcurses-ui-perl suggests no packages.
-- no debconf information