I, too, have Term::ReadLine-1.03, which pretty much rules it out.

I'm pretty much convinced that it is Term::ReadLine, or at least Term::ReadKey, specifically, ReadKey.xs.

And I don't see where any registry key could be influencing this. (Which doesn't mean it ain't so, just that I can't find any place where it could be!)

If you have Devel::Trace handy, could you try running perldl with it enabled?

perl -d:Trace \path\to\perldl.pl
[download]

And see where it comes to rest awaiting input?

On my system it is at >> [0] (eval 9)[C:/Perl64/lib/Term/ReadKey.pm:522]:    6: ??? (your output may look a little different as I tweaked my Trace.pm).

The press one of the arrow keys see what if any trace you get?

I'm pretty much convinced that it is Term::ReadLine, or at least Term::ReadKey, specifically, ReadKey.xs

Which version of Term::ReadKey do you have ? (I have 2.30.)

Cheers,
Rob

I also have Term::ReadKey v2.30. But here's what I suspect is happening. If I run perldl under Devel::Trace, when it finally stops for input, it does so here:

>> [0] C:/Perl64/lib/Term/ReadKey.pm :  274:     if ( ref($file) ) { r
+eturn $file; }    # Reference is fine
>> [0] (eval 9)[C:/Perl64/lib/Term/ReadKey.pm:522]:    3: ???
>> [0] (eval 9)[C:/Perl64/lib/Term/ReadKey.pm:522]:    7: ???
>> [0] (eval 9)[C:/Perl64/lib/Term/ReadKey.pm:522]:    8: ???
[download]

Now that relates to this runtime generated subroutine:

sub ReadKey {
  my($File) = normalizehandle((@_>1?$_[1]:\*STDIN));
    if ($_[0]) {
        Win32PeekChar($File, $_[0]);
    } else {
        getc $File;
    }
    #if ($_[0]!=0) {return undef if !Win32PeekChar($File, $_[0])};
    #getc $File;
}
[download]

On my system, it goes to the else branch of the if statement, and getc. As far as I am aware, there is no possibility for getc to ever return keystrokes/virtual keycodes that are generated by the extended keys--which is the exact symptoms I am seeing.

However, if I hardcode the if condition to force it to go through the Win32PeekChar() branch, then pressing the extended keys does have an affect!. They don't work, but they are seen.

My (pretty confident) guess is that if you traced perldl, you'd find that pressing the extended keys does have an effect, and if you added a little trace, you'd find that on your system, the code is passing through the upper branch of the if statement. The question then becomes why does it do so for you, and not for ikegami and me.

And that's where life gets messy, because the controlling factor of which branch the code takes is down to the arguments passed in from Term::ReadLine()--which is a crufty old module that stems from Perl4 and still has all the leftovers; no strict vars; global variables; the works.

Specifically, the upper branch and Win32PeekChar() will only be called if the first argument to ReadKey() is true. But on my system, the call to ReadKey() comes from line 2082 of Term::ReadLine.pm:

sub rl_getc {
      my $key;                        # JP: Added missing declaration
      if (defined $term_readkey) { # XXXX ???
        $Term::ReadLine::Perl::term->Tk_loop 
          if $Term::ReadLine::toloop && defined &Tk::DoOneEvent;
        $key = Term::ReadKey::ReadKey(0, $term_IN); ### 2082
      } else {
        $key = $Term::ReadLine::Perl::term->get_c;
      }
}
[download]

But there, the first argument is hardcoded to be false (0), so (assuming your system is taking another path), it must be arriving in ReadKey() via a different route. Your first reaction is likely to be to look at $term_readkey (mine was), but I think that is a read herring. It simply records whether Term::ReadKey was successfully loaded.

rl_gets() is only called in one place:

sub getc_with_pending {

    my $key = @Pending ? shift(@Pending) : &$rl_getc;

    # Save keystrokes for vi '.' command
    push(@$Dot_buf, $key) if $Dot_buf;

    $key;
}
[download]

Unfortunately, that gets called all over the place, so that stops my investigation in it's tracks. At least until (if) you trace yours through to see what's different.

My best guess at this point. Are you a vi or emacs user? Do you have some environment variable (say:'editor' or similar) that might influence the behaviour of Term::*?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Same.

Did you try

perl -MTerm::ReadLine -e"$t=Term::ReadLine->new('test'); 1 while (defi
+ned($t->readline(': ')))"
[download]