in reply to Re^7: Key bindings in the Debugger
in thread Key bindings in the Debugger

Replicated: strawberry perl -v => This is perl 5, version 40, subversion 0 (v5.40.0) built for MSWin32-x64-multi-thread : same results as OP under Windows Terminal & cmd.exe or Windows Terminal & powershell

  DB<2> x Term::ReadLine->ReadLine
0  'Term::ReadLine::Perl'

[download]

c:> chcp
Active code page: 437

c:> chcp 65001
Active code page: 65001

c:> perl -wde 1
Can't figure out your console, using stdin: No such file or directory

Loading DB routines from perl5db.pl version 1.80
Editor support available.

Enter h or 'h h' for help, or 'perldoc perldebug' for more help.

main::(-e:1):   1
  DB<1> x "§"
0  '§'

[download]

CP437 only has § in the 0x15, which is in the control codes section, so maybe upder CP437, it's being treated as a NAK which might confuse Term::ReadLine

Switching back to powershell, the chcp 65001 doesn't fix everything, because when I paste in 

x "§"

[download]
I get 
x "§"

Specifically:

PS C:\Users\pryrt> chcp
Active code page: 437
PS C:\Users\pryrt> chcp 65001
Active code page: 65001
PS C:\Users\pryrt> perl -wde 1
Can't figure out your console, using stdin: No such file or directory

Loading DB routines from perl5db.pl version 1.80
Editor support available.

Enter h or 'h h' for help, or 'perldoc perldebug' for more help.

main::(-e:1):   1
  DB<1> x "§"
0  '§'
  DB<2> x Win32::GetACP()
0  1252
  DB<3> x Win32::GetOEMCP()
0  437
  DB<4> x Win32::GetConsoleCP()
0  65001
  DB<5> x Win32::GetConsoleOutputCP()
0  437

when looking at the same Win32 functions under the now-working cmd.exe environment, the difference is that Win32::GetConsoleOutputCP() is 65001, not 437.

So then in the powershell window, I tried: 

  DB<6> Win32::SetConsoleOutputCP(65001)

  DB<7> x "§"
0  '§'

[download]

Yep.

Hope this helps.

edits: fix code/pre tags to get § to show up right in the various locations

Replies are listed 'Best First'.
Re^9: Key bindings in the Debugger
by LanX (Saint) on May 26, 2025 at 11:03 UTC
    Thank you!

    Something like this makes sense and reflects my hunch.

    Not sure how Strawberry should address this best.

    • Automatically changing the code page inside the debugger?
    • just warning about it?
    • patching Term::ReadLine backends? (that's a stretch)
    On a side note: I'm surprised that the "Windows Terminal" used the same code page but well...

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    see Wikisyntax for the Monastery

[reply]
      I am not 100% convinced that it's really Strawberry's job. Whenever you are working with text input and output, whether through a standard file interface or through a CLI/console, you are responsible for knowing what your file encoding or console encoding/locale is. Modern Linux helps you out with LANG or LC_ALL usually defaulting to a useful UTF-8-based locale, but it's still up to someone in a Linux environment to know what that setting is on their system; similarly, someone on a Windows system using Strawberry Perl should know (or be willing to research how to know) what codepage settings are relevant. Trying to use a character that's not available in the current encoding will always cause problems, Strawberry or not.

      However, maybe it would be nice if the debugger on Strawberry (or any Windows perl build) would at least tell you the Win32::GetConsoleCP and Win32::GetConsoleOutputCP values (much like it warns you that it cannot figure out the console) -- I don't think Strawberry customizes perl5db.pl , so I believe that means that it would have to be changed in the main perl source code.

      In order to make sure I'm always in UTF-8 mode, I set up the Autorun registry entry for cmd.exe years ago. This conversation prompted me to research, and I have confirmed that I can use the $PROFILE file for powershell to do something similar:

      • cmd.exe sets both the ConsoleCP and ConsoleOutputCP with the chcp command. This can be made automatic using a registry value HKCU\Software\Microsoft\Command Processor\\Autorun = @chcp 65001>NUL for the current user, or the use the same value relative to HKLM for all users
      • In Powershell, using chcp only changes the input encoding, not the output encoding, but there are variables you can set to change the encoding for each. To have this automatically for every Powershell console, you can create or edit the file that the variable $PROFILE resolves to, to add [Console]::InputEncoding = [Console]::OutputEncoding = New-Object System.Text.UTF8Encoding as a line in that profile.

      With those, then when I launch the debugger from either command-line, the codepages are set to 65001 (UTF-8) for both input and output.

[reply]
[d/l]
[select]
        Thanks!

        > I am not 100% convinced that it's really Strawberry's job.

        Neither am I that's why I ask/meditate. (Too many dragons in exaggerated DWIM)

        But Strawberry wouldn't need to patch perl5db.pl, the debugger has config files and so does Perl itself.

        AFAIK did Strawberry and ActivePerl always "localize" the installation to Win.

        Anyhow I think it would be best placed in Term::ReadLine and/or the included backends, the debugger is not the only app relying on ReadLine.

        The simplest approach would be for ReadLine to check if Win32:: is loaded and to warn if control character area is mis-used. The same way setting "Term=dumb" is recommended.

        FWIW I see that ReadLine is capable to return IN / OUT filehandles and I remember it's possible to provide the codepage in the encoding.

        So probably (?) it could be possible that ReadLine adjust itself automatically to the current CP.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery

[reply]

In Section Seekers of Perl Wisdom