Skip Menu |

This queue is for tickets about the TermReadKey CPAN distribution.

Report information
The Basics
Id: 68382
Status: open
Priority: 0/
Queue: TermReadKey

People
Owner: Nobody in particular
Requestors: perl-diddler [...] tlinx.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: bug-TermReadKey [...] rt.cpan.org
Subject: [perl #90788] Term::ReadKey broken by signal(s)
Date: Sun, 22 May 2011 13:44:34 -0700
To: "OtherRecipients of perl Ticket #90788":;
From: "Father Chrysostomos via RT" <perlbug-followup [...] perl.org>
Bugs in Term::ReadKey should be reported to the CPAN RT queue. I’m going to try a little experiment and forward it there from inside Perl’s RT system. It this proves a disaster, I won’t do it again. :-) On Mon May 16 16:59:38 2011, LAWalsh wrote: Show quoted text
> > This is a bug report for perl from perl-diddler@tlinx.org, > generated with the help of perlbug 1.36 running under perl 5.10.0. > > > ----------------------------------------------------------------- > [Please enter your report here] > > I was using sleep in a program that displays output periodically. > I setup a SIGWINCH handler to get new term size parameters if the > window was resized. > > Then I wanted to add the ability to press keys during the wait > to alter program behavior, and was directed to 'Term::ReadKey' by > 'perlfaq8'. Reading its documentation, showed that it could take > a single parameter to use as a timeout -- allowing it to return > after a keypress OR the timeout. This, however, only works > apart from the SIGWINCH handler. > > Most system calls will return immediately if interupted by a signal, > though some are restartable. Sleep and read calls usually return > immediately. > > However, Term::ReadKey does neither. If interrupted by a SIGWINCH, > it loses it's 'timeout' and waits forever for a key to be pressed. > > Ideally, it would behave like other read calls and return immediately. > > However, if that's not possible, I believe it would be > technically correct behavior if it returned at the end > of the the timeout period (in which case the call wouldn't be useful > to me -- and I'd have to find another solution: likely writing my own > using 'select'. > > The following program demonstrates the problem (or shows a non- > interactive, > working version using sleep, based on a var setting). > --------------- > > #!/usr/bin/perl -w > use strict; > > #select STDERR; $|=1; > select STDOUT; $|=1; # pipin' hot output... > > use Readonly; sub RO(\[$@%]@) {goto &Readonly}; > use POSIX qw{sigaction}; > > RO my $SIGWINCH => 28; > > my $need_winsize_update = 0; > > sub update_winsize { # update winsize info...and reset flag > $need_winsize_update=0; > } > > my $handler = sub { print "SIGWINCH\n";$need_winsize_update = 1 }; > > sigaction($SIGWINCH, POSIX::SigAction->new( $handler )); > > > # set to 0 uses sleep & SIGWINCH handler works > # set to 1 uses readkey & prog "hangs", (forever), waiting for a key > > # would expect an interrupt to either > # 1) cause an immediate return, (consistent with system read call) > # or (less desirable behavior) > # 2) return when the original wait_time expires > # > > my $use_readkey = 1; > > sub timed_wait ($) { > my $wait_time = $_[0]; > if ($use_readkey) { > use Term::ReadKey; > print "Enter Readkey ($wait_time)..."; > ReadMode 3; > my $char = ReadKey $wait_time; > ReadMode 0; > print "Exit Readkey.\n"; > } else { > print "Enter sleep ($wait_time)..."; > sleep $wait_time; > print "Exit sleep.\n"; > } > } > > > while (1) { > timed_wait 3; > if ($need_winsize_update) { > print "Need Winsize_update!"; > update_winsize(); > } > } > > # vim: ts=2 sw=2 > > --------------- > > > [Please do not change anything below this line] > ----------------------------------------------------------------- > --- > Flags: > category=library > severity=medium > --- > This perlbug was built using Perl 5.10.0 - Fri Jul 30 00:12:10 UTC > 2010 > It is being executed now by Perl 5.10.0 - Thu Sep 16 16:14:28 UTC > 2010. > > Site configuration information for perl 5.10.0: > > Configured by abuild at Thu Sep 16 16:14:28 UTC 2010. > > Summary of my perl5 (revision 5 version 10 subversion 0) > configuration: > Platform: > osname=linux, osvers=2.6.31, archname=x86_64-linux-thread-multi > uname='linux build35 2.6.31 #1 smp 2010-01-06 16:07:25 +0100 > x86_64 x86_64 x86_64 gnulinux ' > config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr > -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm > -Duseshrplib=true -DEBUGGING=both -Doptimize=-fmessage-length=0 -O2 > -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables > -fasynchronous-unwind-tables -Wall -pipe > -Accflags=-DPERL_USE_SAFE_PUTENV' > hint=recommended, useposix=true, d_sigaction=define > useithreads=define, usemultiplicity=define > useperlio=define, d_sfio=undef, uselargefiles=define, > usesocks=undef > use64bitint=define, use64bitall=define, uselongdouble=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE > -DPERL_USE_SAFE_PUTENV -DDEBUGGING -fno-strict-aliasing -pipe > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', > optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 > -fstack-protector -funwind-tables -fasynchronous-unwind-tables > -Wall -pipe -g', > cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV > -DDEBUGGING -fno-strict-aliasing -pipe' > ccversion='', gccversion='4.4.1 [gcc-4_4-branch revision 150839]', > gccosandvers='' > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 > d_longlong=define, longlongsize=8, d_longdbl=define, > longdblsize=16 > ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes=8, prototype=define > Linker and Libraries: > ld='cc', ldflags =' -L/usr/local/lib64' > libpth=/lib64 /usr/lib64 /usr/local/lib64 > libs=-lm -ldl -lcrypt -lpthread > perllibs=-lm -ldl -lcrypt -lpthread > libc=/lib64/libc-2.10.1.so, so=so, useshrplib=true, > libperl=libperl.so > gnulibc_version='2.10.1' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E > -Wl,-rpath,/usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/CORE' > cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64' > > Locally applied patches: > > > --- > @INC for perl 5.10.0: > /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi > /usr/lib/perl5/5.10.0 > /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi > /usr/lib/perl5/site_perl/5.10.0 > /usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi > /usr/lib/perl5/vendor_perl/5.10.0 > /usr/lib/perl5/vendor_perl > . > > --- > Environment for perl 5.10.0: > HOME=/home/law > LANG=en_US.UTF-8 > LANGUAGE (unset) > LC_CTYPE=en_US.UTF-8 > LD_LIBRARY_PATH=/usr/lib64/mpi/gcc/openmpi/lib64 > LOGDIR (unset) >
PATH=.:/sbin:/usr/local/sbin:/usr/lib64/mpi/gcc/openmpi/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/sbin Show quoted text
> PERL_BADLANG (unset) > SHELL=/bin/bash
From: perl-diddler [...] tlinx.org
FYI... 1 year later... This bug is still present in Perl 5.14.2 / Term::ReadKey 2.30 on SuSE linux, 12.1, linux kernel 3.1.3 x86_64 SMP PREEMPT ...
Why is requestor set to be perlbug followup and not the bug reporter? Seems like that tends to mess up reports -- as in -- looking at the bugs reported by same person -- I saw lots of junk. then I realized the bug was listed as requested by a generic-remailing address---which doesn't seem right.
On Thu Jul 19 12:50:06 2012, LAWALSH wrote: Show quoted text
> Why is requestor set to be perlbug followup and not the bug reporter? > > Seems like that tends to mess up reports -- as in -- looking at the bugs > reported by same person -- I saw lots of junk. then I realized the bug > was listed as requested by a generic-remailing address---which doesn't > seem right. >
so that the other ticket and anyone watching it get notified.
On Thu Jul 19 13:35:43 2012, ikegami wrote: Show quoted text
> On Thu Jul 19 12:50:06 2012, LAWALSH wrote:
> > Why is requestor set to be perlbug followup and not the bug reporter? > > > > Seems like that tends to mess up reports -- as in -- looking at the bugs > > reported by same person -- I saw lots of junk. then I realized the bug > > was listed as requested by a generic-remailing address---which doesn't > > seem right. > >
> > > so that the other ticket and anyone watching it get notified.
Adding yourself as a requester is one thing, but deleting someone else??? I can't readd it.
Subject: Re: [rt.cpan.org #68382] [perl #90788] Term::ReadKey broken by signal(s)
Date: Thu, 19 Jul 2012 14:46:27 -0700
To: bug-TermReadKey [...] rt.cpan.org
From: Linda W <perl-diddler [...] tlinx.org>
ikegami via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=68382 > > > On Thu Jul 19 13:35:43 2012, ikegami wrote: >
>> On Thu Jul 19 12:50:06 2012, LAWALSH wrote: >>
>>> Why is requestor set to be perlbug followup and not the bug reporter? >>> >>> Seems like that tends to mess up reports -- as in -- looking at the bugs >>> reported by same person -- I saw lots of junk. then I realized the bug >>> was listed as requested by a generic-remailing address---which doesn't >>> seem right. >>> >>>
>> so that the other ticket and anyone watching it get notified. >>
> > Adding yourself as a requester is one thing, but deleting someone > else??? I can't readd it. >
The proper place for the interested party list is the Cc list.. Not as the requester.
Why is this listed as "stalled?" (or what, exactly, does that mean?) No one is owns this? FWIW, 2.5 years after 1st submitted -- this is still broken. Have a prog that tries to poll for input (has to keep updating a display), that still breaks (stops returning) if a window size change happens. It appears the WINCH sig causes the timeout to be ignored, and the readkey becomes a wait-for-key, readkey, as pressing 'ENTER' will cause it to resume screen refreshes...
Subject: Re: [rt.cpan.org #68382] [perl #90788] Term::ReadKey broken by signal(s)
Date: Sun, 08 Dec 2013 10:47:55 +0000
To: bug-TermReadKey [...] rt.cpan.org
From: Jonathan Stowe <jonathan.stowe [...] gmail.com>
Hi, It is "stalled" because it wasn't immediately clear to me how to fix it and I wanted to fix some of the more tractable problems before making a release. What appears to be happening is that the signal is interrupting the select and it's not obvious how to restart that when the signal handler is complete. It will get fixed, I just don't have a much time to dedicate to maintaining the module as I did when I first took it on. On Sat, 2013-12-07 at 19:12 -0500, Linda A Walsh via RT wrote: Show quoted text
> Queue: TermReadKey > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=68382 > > > Why is this listed as "stalled?" (or what, exactly, does that mean?) No one is owns this? > > > FWIW, 2.5 years after 1st submitted -- this is still broken. Have a prog that tries to poll for input (has to keep updating a display), that still breaks (stops returning) if a window size change happens. > > It appears the WINCH sig causes the timeout to be ignored, and the readkey becomes a wait-for-key, readkey, as pressing 'ENTER' will cause it to resume screen refreshes... >