Term::ReadKey on Win? 5.005 vs 5.8.8?

[Ilya Zakharevich]

I'm trying to design a workaround for Perl PerlIO bugs...

Could people with working Term::ReadKey determine what happens on
pressing Enter key (possbly many times, if needed)? E.g., please run
both

perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die; binmode $in or die; ReadMode 4, $in; $|=1; print ord while defined($_=getc)"
perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die;
ReadMode 4, $in; $|=1; print ord while defined($_=getc)"

(one with binmode, another without). If possible, use pre-5.6 Perl
and one of the current Perls, 5.8.7 and 5.8.8. Especially interesting
is to know how many Enter keypresses are needed to get "some action",
and how many lines are printed when "an action" happens.

A lot of thanks,
Ilya

 

[Dr.Ruud]

Ilya Zakharevich schreef:

perl -MTerm::ReadKey
-wle "open $in, '+< CONIN$' or die;
ReadMode 4, $in;
$|=1;
print ord while defined($_=getc)"

I had to change that to

perl -MTerm::ReadKey
-wle 'open ($in, "+< /dev/tty") or die $!;
ReadMode 4, $in;
$|=1; print ord while defined($_=getc) and 3!=ord;
ReadMode 0, $in'

to make it do anything, and to be able to orderly stop it.
(perl, v5.8.6 built for i386-freebsd-64int)

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Dr.Ruud

I had to change that to

perl -MTerm::ReadKey
-wle 'open ($in, "+< /dev/tty") or die $!;

Well, I'm not interested in /dev/tty, only in CONIN$.

ReadMode 4, $in;
$|=1; print ord while defined($_=getc) and 3!=ord;

My understanding is that Control-Break should stop the application on Win.

ReadMode 0, $in'

Actually, I do not know; does Term::ReadKey changes the state of TTY
for the parent process on Win*?

to make it do anything, and to be able to orderly stop it.
(perl, v5.8.6 built for i386-freebsd-64int)

Thanks,
Ilya

 

[Mothra]

Hi Ilya,

I'm trying to design a workaround for Perl PerlIO bugs...

Could people with working Term::ReadKey determine what happens on
pressing Enter key (possbly many times, if needed)? E.g., please run
both

perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die; binmode $in
or die; ReadMode 4, $in; $|=1; print ord while defined($_=getc)"
perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die;
ReadMode 4, $in; $|=1; print ord while defined($_=getc)"

(one with binmode, another without). If possible, use pre-5.6 Perl
and one of the current Perls, 5.8.7 and 5.8.8. Especially interesting
is to know how many Enter keypresses are needed to get "some action",
and how many lines are printed when "an action" happens.

A lot of thanks,
Ilya

D:\perl_modules\TermReadKey-2.30>perl -MTerm::ReadKey -wle "open $in, '+< CON
' or die; $in or die; ReadMode 4, $in; $|=1; print ord while defined($_=getc
13
13
13
255

D:\perl_modules\TermReadKey-2.30>perl -MTerm::ReadKey -wle "open $in, '+< CON
' or die; binmode $in or die; ReadMode 4, $in; $|=1; print ord while defined
=getc)"
13
13
13
255

D:\perl_modules\TermReadKey-2.30>perl -v

This is perl, v5.8.6 built for MSWin32-x86-multi-thread
(with 3 registered patches, see perl -V for more detail)

Copyright 1987-2004, Larry Wall

I had to press enter once in order for it to work.

Hope this helps

Mothra

 

[Dr.Ruud]

Ilya Zakharevich schreef:

(e-mail address removed):

[attribution repaired] Ilya:

perl -MTerm::ReadKey
-wle "open $in, '+< CONIN$' or die;
ReadMode 4, $in;
$|=1;
print ord while defined($_=getc)"

I had to change that to

perl -MTerm::ReadKey
-wle 'open ($in, "+< /dev/tty") or die $!;

Well, I'm not interested in /dev/tty, only in CONIN$.

I totally missed the "Win" in the Subject. I assume now that CONIN$ is
Windows-specific.

My understanding is that Control-Break should stop the application on
Win.

I used a cygwin-ssh connection to a FreeBSD system. A Control-Break
stopped the ssh-connection too, so I had to log on again.

Actually, I do not know; does Term::ReadKey changes the state of TTY
for the parent process on Win*?

I think it gets restored. Not so on the freebsd-perl.


Now my results for "perl, v5.8.8 built for MSWin32-x86-multi-thread":

Both with or without binmode:
The first Ctrl-M shows nothing, the second Ctrl-M neither, the third
Ctrl-M neither, the fourth Ctrl-M shows a single "13", a Ctrl-A recovers
2 of the missing "13"s and also prints a "1".



BTW, "cmd" knows "/dev/con", test:

C:\> echo abc > /dev/con

but Term::ReadKey doesn't seem to support that.

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Mothra

I had to press enter once in order for it to work:

D:\perl_modules\TermReadKey-2.30>perl -MTerm::ReadKey -wle "open $in, '+< CON
' or die; $in or die; ReadMode 4, $in; $|=1; print ord while defined($_=getc
13
13
13
255

This is very strange (and contrary to what other reports say about how
Term::ReadKey behaves)... Without binmode() the first Enter should
not do anything. Are you sure that you did not need multiple presses
with this invocation?

D:\perl_modules\TermReadKey-2.30>perl -MTerm::ReadKey -wle "open $in, '+< CON
' or die; binmode $in or die; ReadMode 4, $in; $|=1; print ord while defined
=getc)"
13
13
13
255

Thanks. This shows that Win* sends \r instead of \n (which any other
OS I know sends). Could you also check which keys are generated by
Control-Enter, Control-M and Control-J?

A lot of thanks,
Ilya

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Dr.Ruud

I totally missed the "Win" in the Subject. I assume now that CONIN$ is
Windows-specific.

Yes, see below.

I think it gets restored.

I would like to hear about it more. As reported to me, cygwin's
stty.exe DOES change the state of TTY for the parent process - even if
the parent process is not cygwin!

Not so on the freebsd-perl.

Yes, *nix has a (broken?) semantic that TTY state is a property of a
physical TTY, not of a process' filehandle.

Now my results for "perl, v5.8.8 built for MSWin32-x86-multi-thread":

Both with or without binmode:
The first Ctrl-M shows nothing, the second Ctrl-M neither, the third
Ctrl-M neither, the fourth Ctrl-M shows a single "13", a Ctrl-A recovers
2 of the missing "13"s and also prints a "1".

Wow! Even without binmode... Again, this contradicts other reports I
saw from users of Term::ReadLine...

BTW, "cmd" knows "/dev/con", test:

C:\> echo abc > /dev/con

but Term::ReadKey doesn't seem to support that.

Known bug in Win* device driver. Googling for

conin readkey readmode con

brings the relevant discussion in the first hit. Now
Term::ReadLine:erl has a workaround for this bug - but it triggers
this "4 Enters" syndrom.

Sigh,
Ilya

 

[Mothra]

[A complimentary Cc of this posting was sent to
Mothra

I had to press enter once in order for it to work:

D:\perl_modules\TermReadKey-2.30>perl -MTerm::ReadKey -wle "open
$in, '+< CON ' or die; $in or die; ReadMode 4, $in; $|=1; print ord
while defined($_=getc 13
13
13
255

This is very strange (and contrary to what other reports say about how
Term::ReadKey behaves)... Without binmode() the first Enter should
not do anything. Are you sure that you did not need multiple presses
with this invocation?

The first enter did nothing (in both examples) I guess I should have been
more clear on that.

Thanks. This shows that Win* sends \r instead of \n (which any other
OS I know sends). Could you also check which keys are generated by
Control-Enter, Control-M and Control-J?

With or without binmode the results are the same. Pressing
Control-Enter produced no output, Control-M produced
13 and Control-J produced no output.

Hope this helps

Mothra

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Mothra

The first enter did nothing (in both examples) I guess I should have been
more clear on that.

Thanks. So could you please be "more clear on that"? ;-)

What happens on what keypress (separately for binmode vs no-binmode)?

With or without binmode the results are the same. Pressing
Control-Enter produced no output, Control-M produced
13 and Control-J produced no output.

Thanks; and what happens if you press some other keys AFTER these? Is
any output "delayed" until other keypresses?

A lot of thanks for your patience,
Ilya

 

[Sisyphus]

"Ilya Zakharevich" <[email protected]>
..
..

What happens on what keypress (separately for binmode vs no-binmode)?

Haven't yet detected any difference between binmode and no-binmode.

first press - this just enters the command, nothing happens except the
cursor drops down one line
second press - nothing happens
third press - nothing happens
fourth press - nothing happens
fifth press - 13, cursor moves down one line

Then, for each subsequent press of 'Enter', one more '13' appears and the
cursor drops down one line.

Then, If I hit a key other than Enter or Ctrl-M, let's say Ctrl-C, I get 13,
13, and 3 (in that order and on separate lines).

Then if I go back to hitting 'Enter':
first press - nothing happens
second press - nothing happens
third press - nothing happens
fouth press - 13, cursor moves down one line

Then, for each subsequent press of 'Enter', one more '13' appears and the
cursor drops down one line.

Then, If I hit a key other than Enter, let's say 'e', I get 13, 13, and 101
(in that order and on separate lines).

And so on .........

Afaict the behaviour of Ctrl-M is identical to the 'Enter' key in every way.
That is, Ctrl-M produces 13, and it also has exactly the same
latency/re-emergence properties as the Enter key. In fact, as far
asTerm::ReadKey is concerned, 'Ctrl-M' and 'Enter' are the same
(indistinguishable) key

press 'e' - 101
press Ctrl-M - nothing
press Ctrl-M - nothing
press Ctrl-M - nothing
press Ctrl-M - 13
press Enter - 13

or

press 'e' - 101
press Enter - nothing
press Ctrl-M - nothing
press Enter - nothing
press Ctrl-M - 13
press Enter - 13

or any other permutation of 'Ctrl-M' and 'Enter' produces the same output.

I've done most of this using the no-binmode version. Did you have something
more specific in mind re checking for differences between binmode and
no-binmode ? (I might've missed something - though I don't think I have.)

I ran it on perl 5.8.8 - one version built using MSVC++ 7.0 and another
using MinGW. Couldn't detect any difference between the 2 builds.

On Windows 2000.

Cheers,
Rob

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Sisyphus

Haven't yet detected any difference between binmode and no-binmode.

first press - this just enters the command, nothing happens except the
cursor drops down one line
second press - nothing happens
third press - nothing happens
fourth press - nothing happens
fifth press - 13, cursor moves down one line

Then, for each subsequent press of 'Enter', one more '13' appears and the
cursor drops down one line.

Then, If I hit a key other than Enter or Ctrl-M, let's say Ctrl-C, I get 13,
13, and 3 (in that order and on separate lines).

Thank you a lot. Now if could get a mental model of what kind of bug
could cause this...

Yours,
Ilya

 

[Sisyphus]

..
..>

Thank you a lot. Now if could get a mental model of what kind of bug
could cause this...

Fwiw, the bug can be demonstrated with a simpler command:

perl -MTerm::ReadKey -e "ReadMode 4;while(1){$k = getc; print ord($k),
\"\n\"}"

Switching to 'ReadMode 0' in the above command means I have to hit 'Enter'
after I enter the character. So:

press 'a' and the letter 'a' appears
press 'Enter' and I end up with:

a
97
10

then press b and I've got:

a
97
10
b

then press 'Enter' again and I've got:

a
97
10
b
98
10


I don't really understand what's happening (nor do I feel a need to
understand this) - I just thought it might be noteworthy that I now seem to
get a '10' for the 'Enter', rather than a '13'. (And, of course, the bug is
no longer evident.)

Cheers,
Rob

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Sisyphus

Fwiw, the bug can be demonstrated with a simpler command:

perl -MTerm::ReadKey -e "ReadMode 4;while(1){$k = getc; print ord($k),
\"\n\"}"

I presume you meant to print

perl -MTerm::ReadKey -wle "ReadMode 4; print ord getc while 1"

But this is not what I'm interested in; you are reading from STDIN; it
may be CONIN$, but maybe it is not. Could you check the file name to
which STDIN is connected? On OS/2 POSIX::ttyname() would work; do not
know about Win*...

Switching to 'ReadMode 0' in the above command means

Sorry, I can't understand what is the purpose of the rest of your
message... Do you change 4 to 0 in the above code? Then what you do
is just

perl -wle "print ord getc while 1"

and I do not see anything deserving attention in how you describe its
effects. :-(

Thanks anyway,
Ilya

 

[robic0]

I'm trying to design a workaround for Perl PerlIO bugs...

Could people with working Term::ReadKey determine what happens on
pressing Enter key (possbly many times, if needed)? E.g., please run
both

perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die; binmode $in or die; ReadMode 4, $in; $|=1; print ord while defined($_=getc)"
perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die;
ReadMode 4, $in; $|=1; print ord while defined($_=getc)"

(one with binmode, another without). If possible, use pre-5.6 Perl
and one of the current Perls, 5.8.7 and 5.8.8. Especially interesting
is to know how many Enter keypresses are needed to get "some action",
and how many lines are printed when "an action" happens.

A lot of thanks,
Ilya

You should avoid Term:: entirely. Under windows api, terminal is bad enough and loaded with problems.
Jumping up a level in Perl is a thousand times worst.

 

[Dr.Ruud]

Ilya Zakharevich schreef:

Now if could get a mental model of what kind of bug
could cause this...

I read the code for a few minutes and then tested this:

C:\>perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die $!;
ReadMode 4, $in;
$|=1;
print ord while defined($_=ReadKey 0)"


C:\>perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die $!;
ReadMode 4, $in;
$|=1;
print ord while defined($_=ReadKey
'0E0')"

(perl, v5.8.8 built for MSWin32-x86-multi-thread)

 

[Sisyphus]

"Ilya Zakharevich" <[email protected]>
..
..
..

Could you check the file name to
which STDIN is connected? On OS/2 POSIX::ttyname() would work; do not
know about Win*...

I don't know about Windows either. POSIX::ttyname() is not implemented.

perl -wle "print ord getc while 1"

and I do not see anything deserving attention in how you describe its
effects. :-(

I thought it might be noteworthy that the ord() for the 'Enter' and 'Ctrl-M'
keys seemed to change from 13 to 10. No matter.

I *did* preface my post with 'fwiw' ...... with good reason, it seems

Cheers,
Rob

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Sisyphus

I don't know about Windows either. POSIX::ttyname() is not implemented.

Anyway, there must be a way to list (names of) files opened by a
process. Usually named lsof or similarly.

I thought it might be noteworthy that the ord() for the 'Enter' and 'Ctrl-M'
keys seemed to change from 13 to 10. No matter.

well, it must be 10 in cooked non-binary mode. The surprise is that
it is 13 in raw mode... Another surprise is that Win-specific code is
smart enough to ignore text-mode on raw filehandles...

Thanks,
Ilya

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Dr.Ruud

I read the code for a few minutes and then tested this:

Is not a part of your message missing?

C:\>perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die $!;
ReadMode 4, $in;
$|=1;
print ord while defined($_=ReadKey 0)"

This has a low probablity to be useful. Whatever happens is a side
effect of changing ReadMode on one filehandle, and testing the results
on another. As Sysiphus already tested, STDIN opened to "default TTY"
acts the same as CONIN$...

Thanks,
Ilya

 

[Dr.Ruud]

Ilya Zakharevich schreef:

Dr.Ruud:

Is not a part of your message missing?
Huh?



This has a low probablity to be useful. Whatever happens is a side
effect of changing ReadMode on one filehandle, and testing the results
on another. As Sysiphus already tested, STDIN opened to "default TTY"
acts the same as CONIN$...

I get the same results with "ReadKey 0, $in" vs. "ReadKey '0E0', $in".

I didn't get why you use "getc" and not "ReadKey" (which not always uses
"getc").
See perldoc Term::ReadKey, under ReadKey MODE [, Filehandle], at the end
it mentions Windows and getc.

I was pointing to the difference between calling ReadKey with 0 and with
'0E0'. The first has the "erratic" behaviour, the second not. See the
conditionals involved in the source.

My conclusion at this moment: don't use "getc" but "ReadKey", and if you
don't want ReadKey to use getc, but still want a blocked read, use MODE
'0E0' (as a workaround).

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Dr.Ruud

Huh?

Eh? All your message contained was "I tested THIS code". No
information about the testing was contained.

I was pointing to the difference between calling ReadKey with 0 and with
'0E0'. The first has the "erratic" behaviour, the second not. See the
conditionals involved in the source.

I get the same results with "ReadKey 0, $in" vs. "ReadKey '0E0', $in".

I do not follow again. Is the result the same, or one `is "erratic"',
other not? And IS it the same as with getc?

I didn't get why you use "getc" and not "ReadKey" (which not always
uses "getc").

Because T:R uses getc().

See perldoc Term::ReadKey, under ReadKey MODE [, Filehandle], at the end
it mentions Windows and getc.

Did not find any mention of what you suggest (0 vs 0e0, Win and getc)
in 2.30.

My conclusion at this moment: don't use "getc" but "ReadKey", and if you
don't want ReadKey to use getc, but still want a blocked read, use MODE
'0E0' (as a workaround).

Again, this looks like contradicting the other parts of your message.

Thanks,
Ilya