Skip Menu |

This queue is for tickets about the TermReadKey CPAN distribution.

Report information
The Basics
Id: 17773
Status: resolved
Priority: 0/
Queue: TermReadKey

People
Owner: jns [...] gellyfish.co.uk
Requestors: adamk [...] cpan.org
Cc:
AdminCc:

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



Subject: Term::ReadKey trouble on Win32 Vanilla Perl.
Installed Term::ReadKey through the CPAN shell as part of my attempts to gradually get Bundle::CPAN working. Built ok, tests went a little funny when I could exit one of the tests, had to force my way out of it, but things still seemed to go ok. After installation, every time I start up the debugger or CPAN shell I get something like the following. ------------------------------------------------------- C:\DOCUME~1\adam\LOCALS~1\Temp\cpan\build\CPAN-1.86>perl -de 1 Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `perldoc perldebug' for more help. main::(-e:1): 1 MYDEBUGGING: Setting mode '' (4) MYDEBUGGING: Normalised handle MYDEBUGGING: SetReadMode( 4, GLOB(0x9852e0) ) SetConsoleMode failed, LastError=|6| at c:/vanilla-perl/perl/site/lib/Term/ReadK ey.pm line 267. at c:/vanilla-perl/perl/site/lib/Term/ReadLine/readline.pm line 1415 readline::readline(' DB<1> ') called at c:/vanilla-perl/perl/site/lib/T erm/ReadLine/Perl.pm line 11 Term::ReadLine::Perl::readline('Term::ReadLine::Perl=ARRAY(0xaabf7c)', ' DB<1> ') called at c:/vanilla-perl/perl/lib/perl5db.pl line 6367 DB::readline(' DB<1> ') called at c:/vanilla-perl/perl/lib/perl5db.pl l ine 2203 DB::DB called at -e line 1 DB<1> --------------------------------------------------------- The MYDEBUGGING lines did not change the error, and were the result of just some print statements I inserted in ReadMode. ---------------------------------------------------------- sub ReadMode { my ($mode) = $modes{ $_[0] }; print "MYDEBUGGING: Setting mode '$mode' ($_[0])\n"; my ($fh) = normalizehandle( ( @_ > 1 ? $_[1] : \*STDIN ) ); print "MYDEBUGGING: Normalised handle\n"; if ( defined($mode) ) { print "MYDEBUGGING: SetReadMode( $mode, $fh )\n"; SetReadMode( $mode, $fh ) } elsif ( $_[0] =~ /^\d/ ) { print "MYDEBUGGING: SetReadMode( $_[0], $fh )\n"; SetReadMode( $_[0], $fh ) } else { croak("Unknown terminal mode `$_[0]'"); } } --------------------------------------------------------- Since I don't see SetReadMode mentioned anywhere else in the file, I'm assuming that it is implemented in XS/C.
CC: bug-TermReadKey [...] rt.cpan.org
Subject: [cpan #17773] Re: Term::ReadKey on Win32
Date: Mon, 27 Feb 2006 14:13:04 +0000
To: Adam Kennedy <cpan [...] ali.as>
From: Jonathan Stowe <jns [...] gellyfish.com>
On Mon, 2006-02-27 at 13:23, Adam Kennedy wrote: Show quoted text
> Hi there > > I'm working on Vanilla Perl, the new non-ActiveState Win32 perl > distribution, trying to work my way through the bugs in the standard > tool chain (basically, what's in Bundle::CPAN) and I'm through most of > them now, except for some problems in Term::ReadKey (and a couple of others) > > I was wondering what your situation was WRT being able to look at the > Win32-related Term::ReadKey bugs. Could you use some help if I could > draft in others? > > Just looking for an update really. >
It appears you have me at a disadvantage, I was not aware of any outstanding 'bugs' in Term::ReadKey until I received this, since RT was upgraded I don't appear to see the TermReadKey queue nor get any email notifications of new tickets. It also appears that I can't take the tickets so it's not a very good way of making bug reports to me. Anyway, I'm going to need more information from you before I can look at this because from your report I'm not actually sure it is a 'bug', this looks like a class of problem on Win32 that arises due to the build environment for a module differing from that used to build the perl itself (you can find discussion of this on p5p.) Please can you send me the output from perl -V and the versions of both the compiler used to build the perl and that used to build the module. /J\ -- This e-mail is sponsored by http://www.integration-house.com/
CC: bug-TermReadKey [...] rt.cpan.org
Subject: Re: [cpan #17773] Re: Term::ReadKey on Win32
Date: Mon, 27 Feb 2006 22:45:04 +0000
To: Adam Kennedy <cpan [...] ali.as>
From: Jonathan Stowe <jns [...] gellyfish.com>
On Mon, 2006-02-27 at 14:13, Jonathan Stowe wrote: Show quoted text
> On Mon, 2006-02-27 at 13:23, Adam Kennedy wrote:
> > Hi there > > > > I'm working on Vanilla Perl, the new non-ActiveState Win32 perl > > distribution, trying to work my way through the bugs in the standard > > tool chain (basically, what's in Bundle::CPAN) and I'm through most of > > them now, except for some problems in Term::ReadKey (and a couple of others) > > > > I was wondering what your situation was WRT being able to look at the > > Win32-related Term::ReadKey bugs. Could you use some help if I could > > draft in others? > > > > Just looking for an update really. > >
> > It appears you have me at a disadvantage, I was not aware of any > outstanding 'bugs' in Term::ReadKey until I received this, since RT was > upgraded I don't appear to see the TermReadKey queue nor get any email > notifications of new tickets. It also appears that I can't take the > tickets so it's not a very good way of making bug reports to me. > > Anyway, I'm going to need more information from you before I can look at > this because from your report I'm not actually sure it is a 'bug', this > looks like a class of problem on Win32 that arises due to the build > environment for a module differing from that used to build the perl > itself (you can find discussion of this on p5p.) Please can you send me > the output from perl -V and the versions of both the compiler used to > build the perl and that used to build the module.
I thought I might try and satisfy myself that there was no other problem going on here and had a little poke around building my own Perl with MS C 7 and trying to replicate the problem. This has turned up what may be either a bug in Term::ReadLine or in perl itself rather than in Term::ReadKey. The problem seems to lie with Term::ReadLine's use of the CON: special file for the console on Windows, now this seems to work fine and you can print to handle opened to it and so on and so forth but it doesn't seem to work with Term::ReadKey. I have tested with a version of Term::ReadLine that I have altered to use the default STDIN and Term::ReadLine::Perl (where you were actually seeing the error) seems to work reasonably fine with no error. I am going to have to wait until tomorrow to workup some better test cases just to narrow down where the problem actually lies and then probably take some further opinion before I proceed. /J\ -- This e-mail is sponsored by http://www.integration-house.com/
CC: bug-TermReadKey [...] rt.cpan.org, Adam Kennedy <cpan [...] ali.as>
Subject: [cpan #17773] Term::ReadLine, CON: and Term::ReadKey on Win32
Date: Tue, 28 Feb 2006 14:07:39 +0000
To: perl5-porters [...] perl.org
From: Jonathan Stowe <jns [...] gellyfish.com>
I've had a few bug reports on Term::ReadKey on Windows where people are getting stuff like: SetConsoleMode failed, LastError=|6| at C:/perl/site/lib/Term/ReadKey.pm line 265. (Where SetConsoleMode is the windows API function being called at the time and the error 6 means 'invalid handle.) I've put these down in the past to packaging problems or a CRT mismatch (see previous discussion here on the rĂ´le of mismatched runtimes between Perl and XS modules with regard to filehandles.) Anyhow in examining the reports like the above I had completely failed to notice that it was SetConsoleMode() and not GetConsoleMode() which is called earlier in the ReadMode() implementation that is failing - if the OS handle that gets passed to one is invalid it should be invalid when it gets passed to the first one as well. Also I hadn't really considered that the reports I was getting were from when people were using either the debugger or the CPAN shell on the whole, what these have in common is that they use Term::ReadLine (and thence Term::ReadLine::readline ). Anyway it seems to boil down to Term::ReadLines use of 'con' as the console device on Windows: if ($^O eq 'MacOS') { $console = "Dev:Console"; } elsif (-e "/dev/tty") { $console = "/dev/tty"; } elsif (-e "con" or $^O eq 'MSWin32') { $console = "con"; } else { $console = "sys\$command"; } Now opening CON: as a file works fine for both reading and writing in Perl programs; it just seems that it doesn't work when you pass a filehandle opened to it to Term::ReadKey::ReadMode, however I'm pretty certain that there is nothing that either Perl or Term::ReadKey is doing wrong and that it is Windows behaviour as exemplified by the result of: #include <windows.h> #include <stdio.h> int main (int argc, char **argv) { HANDLE h; DWORD mode; h = CreateFile("CON:",GENERIC_READ ,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL); if ( h == INVALID_HANDLE_VALUE ) printf("CreateFile failed: %d\n", GetLastError()); if (! GetConsoleMode(h,&mode) ) printf("GetConsoleMode failed: %d\n", GetLastError()); if (! SetConsoleMode(h,mode) ) printf("SetConsoleMode failed: %d\n", GetLastError()); return 0; } Which shows the failure in SetConsoleMode() with the same error code as in the ReadMode failure. Anyway, to cut to the point, should the use of 'CON:' be changed in Term::ReadLine? At simplest we could just set $console to undef in the above snippet, which works (setting the input and output handles to STDIN and STDOUT respectively), but some testing with Term::ReadLine::Perl seems to indicate there might be some blocking (at least in the tests) and I haven't had time to delve to far into that. An alternative would be to further special case Win32 in Term::ReadLine::getConsole and have it sysopen CONIN$ and CONOUT$ as appropriate as they don't seem to be afflicted with the same problem that CON: has. If people want to do that I'll be happy to work up a patch. Or maybe someone has a better idea. I'm also interested in hearing any ideas about the reason for this problem at the windows level - I can't find any reference to it on MSDN or with some light googling and I'm not really sure whether it is a bug or whether it is just an artefact of CON: being there for backward compatibility with MS-DOS 3.0 . /J\ -- This e-mail is sponsored by http://www.integration-house.com/
CC: perl5-porters [...] perl.org, bug-TermReadKey [...] rt.cpan.org, Adam Kennedy <cpan [...] ali.as>
Subject: Re: [cpan #17773] Term::ReadLine, CON: and Term::ReadKey on Win32
Date: Tue, 28 Feb 2006 14:26:23 +0000
To: Jonathan Stowe <jns [...] gellyfish.com>
From: Steve Hay <steve.hay [...] uk.radan.com>
Jonathan Stowe wrote: Show quoted text
> #include <windows.h> > #include <stdio.h> > > int main (int argc, char **argv) > { > HANDLE h; > DWORD mode; > > h = CreateFile("CON:",GENERIC_READ ,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL); > > if ( h == INVALID_HANDLE_VALUE ) > printf("CreateFile failed: %d\n", GetLastError()); > > if (! GetConsoleMode(h,&mode) ) > printf("GetConsoleMode failed: %d\n", GetLastError()); > if (! SetConsoleMode(h,mode) ) > printf("SetConsoleMode failed: %d\n", GetLastError()); > > return 0; > } > > Which shows the failure in SetConsoleMode() with the same error code as > in the ReadMode failure.
The second argument (DWORD dwDesiredAccess) to CreateFile() above is wrong for SetConsoleMode(): you must specify GENERIC_WRITE to use SetConsoleMode(). (And likewise, you need GENERIC_READ for GetConsoleMode().) There is a section about handling consoles in the CreateFile() documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp (near the bottom of the page). ------------------------------------------------ Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
CC: perl5-porters <perl5-porters [...] perl.org>, bug-TermReadKey [...] rt.cpan.org, Adam Kennedy <cpan [...] ali.as>
Subject: Re: [cpan #17773] Term::ReadLine, CON: and Term::ReadKey on Win32
Date: Tue, 28 Feb 2006 16:16:34 +0000
To: Steve Hay <steve.hay [...] uk.radan.com>
From: Jonathan Stowe <jns [...] gellyfish.com>
On Tue, 2006-02-28 at 14:26, Steve Hay wrote: Show quoted text
> Jonathan Stowe wrote:
> > #include <windows.h> > > #include <stdio.h> > > > > int main (int argc, char **argv) > > { > > HANDLE h; > > DWORD mode; > > > > h = CreateFile("CON:",GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL); > > > > if ( h == INVALID_HANDLE_VALUE ) > > printf("CreateFile failed: %d\n", GetLastError()); > > > > if (! GetConsoleMode(h,&mode) ) > > printf("GetConsoleMode failed: %d\n", GetLastError()); > > if (! SetConsoleMode(h,mode) ) > > printf("SetConsoleMode failed: %d\n", GetLastError()); > > > > return 0; > > } > > > > Which shows the failure in SetConsoleMode() with the same error code as > > in the ReadMode failure.
> > The second argument (DWORD dwDesiredAccess) to CreateFile() above is > wrong for SetConsoleMode(): you must specify GENERIC_WRITE to use > SetConsoleMode(). (And likewise, you need GENERIC_READ for > GetConsoleMode().) > There is a section about handling consoles in the CreateFile() > documentation: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp > (near the bottom of the page). >
I had read that, wherein it says: CON GENERIC_READ GENERIC_WRITE Causes CreateFile to fail; GetLastError returns ERROR_FILE_NOT_FOUND. And http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setconsolemode.asp Says: "The handle must have the GENERIC_READ access right" If you set GENERIC_WRITE on the CreateFile(), GetConsoleMode() fails with an invalid handle error and SetConsoleMode() fails with ERROR_INVALID_PARAMETER. The CreateFile() fails if you specify GENERIC_ALL or GENERIC_READ | GENERIC_WRITE The point of the above code was to abstract what happens when you do: use Term::ReadKey; open IN, '<CON'; Term::ReadKey::ReadMode(4,\*IN); which is, in summary, what is causing the problem that I am describing when CON is used as the $console in Term::ReadLine. attempting to sysopen CON with O_RDWR fails as does any attempt at +< or +>> with plain open. But using sysopen on CONIN$ (or CONOUT$) with O_RDWR (or in the above C code with GENERIC_READ | GENERIC_WRITE) does work. So unless I'm missing something else, what Term::ReadLine is doing with 'con' is not going to work. /J\ -- This e-mail is sponsored by http://www.integration-house.com/
CC: perl5-porters [...] perl.org, bug-TermReadKey [...] rt.cpan.org, Adam Kennedy <cpan [...] ali.as>
Subject: Re: [cpan #17773] Term::ReadLine, CON: and Term::ReadKey on Win32
Date: Tue, 7 Mar 2006 07:54:11 -0800
To: Jonathan Stowe <jns [...] gellyfish.com>
From: Yitzchak Scott-Thoennes <sthoenna [...] efn.org>
On Tue, Feb 28, 2006 at 02:07:39PM +0000, Jonathan Stowe wrote: Show quoted text
> Anyway it seems to boil down to Term::ReadLines use of 'con' as the > console device on Windows: > > if ($^O eq 'MacOS') { > $console = "Dev:Console"; > } elsif (-e "/dev/tty") { > $console = "/dev/tty"; > } elsif (-e "con" or $^O eq 'MSWin32') { > $console = "con"; > } else { > $console = "sys\$command"; > } >
... Show quoted text
> Anyway, to cut to the point, should the use of 'CON:' be changed in > Term::ReadLine? At simplest we could just set $console to undef in the > above snippet, which works (setting the input and output handles to > STDIN and STDOUT respectively), but some testing with > Term::ReadLine::Perl seems to indicate there might be some blocking (at > least in the tests) and I haven't had time to delve to far into that.
That wouldn't be good, since the above code presumably wants a console even if STDIN/STDOUT are redirected elsewhere. Show quoted text
> An alternative would be to further special case Win32 in > Term::ReadLine::getConsole and have it sysopen CONIN$ and CONOUT$ as > appropriate as they don't seem to be afflicted with the same problem > that CON: has. If people want to do that I'll be happy to work up a > patch. Or maybe someone has a better idea.
What windows versions do CON(IN|OUT)$ exist on?
CC: perl5-porters <perl5-porters [...] perl.org>, bug-TermReadKey [...] rt.cpan.org, Adam Kennedy <cpan [...] ali.as>
Subject: Re: [cpan #17773] Term::ReadLine, CON: and Term::ReadKey on Win32
Date: Tue, 07 Mar 2006 16:21:08 +0000
To: Yitzchak Scott-Thoennes <sthoenna [...] efn.org>
From: Jonathan Stowe <jns [...] gellyfish.com>
On Tue, 2006-03-07 at 15:54, Yitzchak Scott-Thoennes wrote: Show quoted text
> On Tue, Feb 28, 2006 at 02:07:39PM +0000, Jonathan Stowe wrote:
> > Anyway it seems to boil down to Term::ReadLines use of 'con' as the > > console device on Windows: > > > > if ($^O eq 'MacOS') { > > $console = "Dev:Console"; > > } elsif (-e "/dev/tty") { > > $console = "/dev/tty"; > > } elsif (-e "con" or $^O eq 'MSWin32') { > > $console = "con"; > > } else { > > $console = "sys\$command"; > > } > >
> ...
> > Anyway, to cut to the point, should the use of 'CON:' be changed in > > Term::ReadLine? At simplest we could just set $console to undef in the > > above snippet, which works (setting the input and output handles to > > STDIN and STDOUT respectively), but some testing with > > Term::ReadLine::Perl seems to indicate there might be some blocking (at > > least in the tests) and I haven't had time to delve to far into that.
> > That wouldn't be good, since the above code presumably wants a console > even if STDIN/STDOUT are redirected elsewhere.
Yes, that's what I thought on reflection. Show quoted text
>
> > An alternative would be to further special case Win32 in > > Term::ReadLine::getConsole and have it sysopen CONIN$ and CONOUT$ as > > appropriate as they don't seem to be afflicted with the same problem > > that CON: has. If people want to do that I'll be happy to work up a > > patch. Or maybe someone has a better idea.
> > What windows versions do CON(IN|OUT)$ exist on?
As far as I can determine they have been part of the published Win32 API forever, and the docs all list windows 95 and NT in the 'Applies to' list, some googling even suggests that it's there on Win32s. Is anyone still testing on those older platforms BTW? Anyway, Unless anyone can see a compelling reason for me not to do so, I'll knock up a patch to implement the second alternative in the next couple of days and see how it goes. /J\ -- This e-mail is sponsored by http://www.integration-house.com/
CC: Ilya Zakharevich <ilya [...] Math.Berkeley.EDU>, Steve Hay <steve.hay [...] uk.radan.com>, bug-TermReadKey [...] rt.cpan.org, Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: [cpan #17773] Bug in Term::ReadKey being trigger by a bug in Term::ReadLine
Date: Sat, 11 Mar 2006 10:58:15 +0000
To: Adam Kennedy <adam [...] phase-n.com>
From: Jonathan Stowe <jns [...] gellyfish.com>
(CCing in the TermReadKey rt queue) On Sat, 2006-03-11 at 05:39, Adam Kennedy wrote: Show quoted text
> Relaying a response from Ilya, since I believe he does not participate > in rt.cpan.org or P5P. > > CCing to all the relevant people (and P5P for any other interested > readers). Can you guys thrash this out between you? Let me know if > there's anything I can do to help. > > Thanks > > Adam K > > Ilya Zakharevich wrote:
> > On Sat, Mar 11, 2006 at 01:44:42AM +1100, Adam Kennedy wrote:
> >> Hiya Ilya. > >> > >> I'm down to one last show-stopper warning in my quest to get Win32 Perl sane, > >> and what seemed to be a Term::ReadKey bug, I'm being told is actually a > >> Term::ReadLine bug. (presumably in Term::ReadLine::readline. > >> > >> Can you take a look at this thread? > >> > >> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-02/msg01018.html
> > > > AFAICS, there is no bug in T::R::L. The bug is in the corresponding > > Windows device driver. > >
Yep, my experiments indicate that the CON: device cannot handle being opened in a way that will satisfy the SetConsoleMode() API. CONIN$ works fine. Show quoted text
> > The place to put a workaround is in T::R, where it should open a pair > > CONIN$ CONOUT$ before trying to open CON. > >
Term::ReadKey is being passed the filehandle that is causing the problems, by default if it isn't passed a filehandle then ReadMode will use STDIN which on windows is obtained at perl startup by GetStdHandle() (and has thus been opened by the C runtime with the appropriate mode). However Term::ReadLine needs to explicitly open the console whether STDIO is redirected or not. My initial idea was simply to fix Term::ReadLine's findConsole() to return 'CONIN$' and 'CONOUT$' rather than 'con' for input and output devices and then open 'CONIN$' in Term::ReadLine::new() for reading *and* writing (as required by SetConsoleMode(),) contrary to my previous understanding a simple open with '+<' is sufficient rather than going to sysopen() with O_RDWR. However this doesn't work with respect of Term::ReadLine::Perl (as will be used on windows) as it gets the names of the console devices by calling Term::ReadLine->findConsole() (at line 45 ) and then opens the devices itself rather than using the handles that would be opened by the call to Term::ReadLine->new(). This can be remedied by changing the mode with which the $IN device is opened to '+<' in the line 46. I guess Term::ReadLine::Perl may be able to use the Term::ReadLine handles but there may be other reasons for it doing what it does. Thus fixed the SetConsoleMode() error does indeed go away, however we now have a new problem (at least in the CPAN shell and the Term::ReadLine::Perl tests, I haven't checked in the debugger shell but I guess it's the same:) the input works fine and is echoed to the console except four carriage returns are required to enter the input line (and it is consistently four regardless of the number of characters entered.) I guess one would find the reason for this in Term::ReadLine, but I haven't had the time to examine this. Er, and that's it. /J\ Show quoted text
>
> > Hope this helps, > > Ilya
-- This e-mail is sponsored by http://www.integration-house.com/
CC: Adam Kennedy <adam [...] phase-n.com>, Steve Hay <steve.hay [...] uk.radan.com>, bug-TermReadKey [...] rt.cpan.org, Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: [cpan #17773] Bug in Term::ReadKey being trigger by a bug in Term::ReadLine
Date: Sat, 11 Mar 2006 21:09:52 -0800
To: Jonathan Stowe <jns [...] gellyfish.com>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Sat, Mar 11, 2006 at 10:58:15AM +0000, Jonathan Stowe wrote: Show quoted text
> > > The place to put a workaround is in T::R, where it should open a pair > > > CONIN$ CONOUT$ before trying to open CON.
Show quoted text
> Term::ReadKey is being passed...
Sorry, mea culpa. T::R above was supposed to mean Term::ReadLine. Show quoted text
> My initial idea was simply to fix Term::ReadLine's findConsole() to > return 'CONIN$' and 'CONOUT$' rather than 'con' for input and output > devices
This is what I meant. Show quoted text
> and then open 'CONIN$' in Term::ReadLine::new() for reading > *and* writing (as required by SetConsoleMode(),) contrary to my previous > understanding a simple open with '+<' is sufficient rather than going to > sysopen() with O_RDWR.
Something like open FIN, ($console eq 'CONIN$') ? "+< $console" : "< $console"; # Bug on Win ? Show quoted text
> However this doesn't work with respect of Term::ReadLine::Perl (as will > be used on windows) as it gets the names of the console devices by > calling Term::ReadLine->findConsole() (at line 45 ) and then opens the > devices itself rather than using the handles that would be opened by the > call to Term::ReadLine->new().
I can copy the code above... Show quoted text
> Thus fixed the SetConsoleMode() error does indeed go away, however we > now have a new problem (at least in the CPAN shell and the > Term::ReadLine::Perl tests, I haven't checked in the debugger shell but > I guess it's the same:) the input works fine and is echoed to the > console except four carriage returns are required to enter the input > line (and it is consistently four regardless of the number of characters > entered.)
I observe 2, not 4 on unpatched 5.8.7 on OS/2. This is one of very old bugs in perlio layers; I fixed it about last Fall. Is not it fixed in 5.8.8? Hope this helps, Ilya
CC: Adam Kennedy <adam [...] phase-n.com>, Steve Hay <steve.hay [...] uk.radan.com>, bug-TermReadKey [...] rt.cpan.org, Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: [cpan #17773] Bug in Term::ReadKey being trigger by a bug in Term::ReadLine
Date: Sun, 12 Mar 2006 09:47:34 +0000
To: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
From: Jonathan Stowe <jns [...] gellyfish.com>
On Sun, 2006-03-12 at 05:09, Ilya Zakharevich wrote: Show quoted text
> On Sat, Mar 11, 2006 at 10:58:15AM +0000, Jonathan Stowe wrote:
> > > > The place to put a workaround is in T::R, where it should open a pair > > > > CONIN$ CONOUT$ before trying to open CON.
>
> > Term::ReadKey is being passed...
> > Sorry, mea culpa. T::R above was supposed to mean Term::ReadLine. >
> > My initial idea was simply to fix Term::ReadLine's findConsole() to > > return 'CONIN$' and 'CONOUT$' rather than 'con' for input and output > > devices
> > This is what I meant. >
> > and then open 'CONIN$' in Term::ReadLine::new() for reading > > *and* writing (as required by SetConsoleMode(),) contrary to my previous > > understanding a simple open with '+<' is sufficient rather than going to > > sysopen() with O_RDWR.
> > Something like > > open FIN, > ($console eq 'CONIN$') ? "+< $console" : "< $console"; # Bug on Win >
Yeah, that's the baby :-) I'll send the patch I have for Term::ReadLine when I am back on the machine where I was testing this tomorrow. Show quoted text
> ? >
> > However this doesn't work with respect of Term::ReadLine::Perl (as will > > be used on windows) as it gets the names of the console devices by > > calling Term::ReadLine->findConsole() (at line 45 ) and then opens the > > devices itself rather than using the handles that would be opened by the > > call to Term::ReadLine->new().
> > I can copy the code above... >
Fabulous! Show quoted text
> > Thus fixed the SetConsoleMode() error does indeed go away, however we > > now have a new problem (at least in the CPAN shell and the > > Term::ReadLine::Perl tests, I haven't checked in the debugger shell but > > I guess it's the same:) the input works fine and is echoed to the > > console except four carriage returns are required to enter the input > > line (and it is consistently four regardless of the number of characters > > entered.)
> > I observe 2, not 4 on unpatched 5.8.7 on OS/2. This is one of very > old bugs in perlio layers; I fixed it about last Fall. Is not it > fixed in 5.8.8?
It appears so - I was testing against an rsync'ed maint, I'll check with blead on Monday or maybe someone can find the patch down the back of the sofa and apply it :-) Thanks /J\ -- This e-mail is sponsored by http://www.integration-house.com/
CC: Adam Kennedy <adam [...] phase-n.com>, Steve Hay <steve.hay [...] uk.radan.com>, bug-TermReadKey [...] rt.cpan.org, Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: [cpan #17773] Bug in Term::ReadKey being trigger by a bug in Term::ReadLine
Date: Sun, 12 Mar 2006 03:07:25 -0800
To: Jonathan Stowe <jns [...] gellyfish.com>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Sun, Mar 12, 2006 at 09:47:34AM +0000, Jonathan Stowe wrote: Show quoted text
> > I observe 2, not 4 on unpatched 5.8.7 on OS/2. This is one of very > > old bugs in perlio layers; I fixed it about last Fall. Is not it > > fixed in 5.8.8?
> > It appears so - I was testing against an rsync'ed maint,
Oh, my! Msg ID is 20050927090734.GB3687@math.berkeley.edu change is 25618. It should be there... Yours, Ilya
CC: Adam Kennedy <adam [...] phase-n.com>, Steve Hay <steve.hay [...] uk.radan.com>, bug-TermReadKey [...] rt.cpan.org, Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: [cpan #17773] Bug in Term::ReadKey being trigger by a bug in Term::ReadLine
Date: Mon, 13 Mar 2006 10:26:57 +0000
To: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
From: Jonathan Stowe <jns [...] gellyfish.com>
On Sun, 2006-03-12 at 11:07, Ilya Zakharevich wrote: Show quoted text
> On Sun, Mar 12, 2006 at 09:47:34AM +0000, Jonathan Stowe wrote:
> > > I observe 2, not 4 on unpatched 5.8.7 on OS/2. This is one of very > > > old bugs in perlio layers; I fixed it about last Fall. Is not it > > > fixed in 5.8.8?
> > > > It appears so - I was testing against an rsync'ed maint,
> > Oh, my! Msg ID is > > 20050927090734.GB3687@math.berkeley.edu > > change is 25618. It should be there...
Indeed, I found it almost immediately after I replied yesterday. And using the test case from the original message it appears that the original problem has indeed been fixed, so it would appear that the "four returns required to enter line" problem lies elsewhere. I'll try to isolate a test case that can illustrate this behaviour when I've sent the patches for the original problem. /J\ -- This e-mail is sponsored by http://www.integration-house.com/
CC: bug-TermReadKey [...] rt.cpan.org
Subject: [PATCH lib/Term/ReadLine] Re: [cpan #17773] Bug in Term::ReadKey being trigger by a bug in Term::ReadLine
Date: Mon, 13 Mar 2006 16:09:44 +0000
To: perl5-porters <perl5-porters [...] perl.org>
From: Jonathan Stowe <jns [...] gellyfish.com>
The following is a fix for the console handles created by Term::ReadLine being no good for Term::ReadKey on windows. I guess Ilya will issue a new Term::ReadLine::Perl to quiet the error in the CPAN shell and the debugger. It should be good for blead and maint. --- devel/perl/perl-maint/lib/Term/ReadLine.pm 2006-01-12 19:26:15.000000000 +0000 +++ work/Via/shared/jstowe/perl/lib/Term/ReadLine.pm 2006-03-13 15:46:46.000000000 +0000 @@ -209,13 +209,15 @@ sub findConsole { my $console; + my $consoleOUT; if ($^O eq 'MacOS') { $console = "Dev:Console"; } elsif (-e "/dev/tty") { $console = "/dev/tty"; } elsif (-e "con" or $^O eq 'MSWin32') { - $console = "con"; + $console = 'CONIN$'; + $consoleOUT = 'CONOUT$'; } else { $console = "sys\$command"; } @@ -231,10 +233,10 @@ } } - my $consoleOUT = $console; + $consoleOUT = $console unless defined $consoleOUT; $console = "&STDIN" unless defined $console; if (!defined $consoleOUT) { - $consoleOUT = defined fileno(STDERR) ? "&STDERR" : "&STDOUT"; + $consoleOUT = defined fileno(STDERR) && $^O ne 'MSWin32' ? "&STDERR" : "&STDOUT"; } ($console,$consoleOUT); } @@ -247,8 +249,13 @@ if (@_==2) { my($console, $consoleOUT) = $_[0]->findConsole; - open(FIN, "<$console"); - open(FOUT,">$consoleOUT"); + + # the Windows CONIN$ needs GENERIC_WRITE mode to allow + # a SetConsoleMode() if we end up using Term::ReadKey + open FIN, ( $^O eq 'MSWin32' && $console eq 'CONIN$' ) ? "+<$console" : + "<$console"; + open FOUT,">$consoleOUT"; + #OUT->autoflush(1); # Conflicts with debugger? my $sel = select(FOUT); $| = 1; # for DB::OUT -- This e-mail is sponsored by http://www.integration-house.com/
I think this was sorted