Num Lock inverse behavior. #10456

Closed
opened 2026-01-31 02:22:03 +00:00 by claunia · 7 comments
Owner

Originally created by @furyd0gg on GitHub (Sep 2, 2020).

So when I enter my root password which has numbers in it, I use the numeric keypad. The bug is that when the num lock is activated the numbers do not work and when it is deactivated it does work. I have tried to open the Windows Terminal with the num lock off and activate it when it is running but it still has this bug.

Originally created by @furyd0gg on GitHub (Sep 2, 2020). So when I enter my root password which has numbers in it, I use the numeric keypad. The bug is that when the num lock is activated the numbers do not work and when it is deactivated it does work. I have tried to open the Windows Terminal with the num lock off and activate it when it is running but it still has this bug.
Author
Owner

@furyd0gg commented on GitHub (Sep 2, 2020):

I forgot to mention that this bug only happens entring root passoword.

@furyd0gg commented on GitHub (Sep 2, 2020): I forgot to mention that this bug only happens entring root passoword.
Author
Owner

@jdebp commented on GitHub (Sep 10, 2020):

You really need to tell people what the thing is that is running using Windows Terminal for its I/O here. Is it WSL? If so, what application program is running on WSL? sudo? login? cat?

@jdebp commented on GitHub (Sep 10, 2020): You really need to tell people what the thing is that is running using Windows Terminal for its I/O here. Is it WSL? If so, what application program is running on WSL? `sudo`? `login`? `cat`?
Author
Owner

@furyd0gg commented on GitHub (Sep 14, 2020):

The bug only happens when entring root password.

@furyd0gg commented on GitHub (Sep 14, 2020): The bug only happens when entring root password.
Author
Owner

@DHowett commented on GitHub (Sep 14, 2020):

Terminal can't know that you're entering a password--especially not specifically your root password--at that point.

Is it possible that your root password was set with numlock in the reverse state, and now it appears as though you have to turn numlock off to make it work?

If you reset the password with passwd to a version where you make sure numlock is on... does it then work?

@DHowett commented on GitHub (Sep 14, 2020): Terminal can't know that you're entering a password--especially not specifically your root password--at that point. Is it possible that your root password was set with numlock in the reverse state, and now it appears as though you have to turn numlock _off_ to make it work? If you reset the password with `passwd` to a version where you make sure numlock is _on_... does it then work?
Author
Owner

@furyd0gg commented on GitHub (Sep 16, 2020):

Still not working.

@furyd0gg commented on GitHub (Sep 16, 2020): Still not working.
Author
Owner

@DHowett commented on GitHub (Sep 18, 2020):

Thanks for the info.

I'm going to ask you to reproduce the issue with the the debug window enabled.
This will expose your password, so I suggest that you change your root password to one that can reproduce this bug but is not your actual password.

If you are willing to do that, follow the steps below.

How to capture debugging information
  1. Edit your settings to add "debugFeatures": true, at the top (under the first {)
  2. Open Terminal
  3. Open the new tab dropdown
  4. Hold down Left Alt and Right Alt at the same time
  5. Launch the profile that you're having trouble with
  6. Release Alts
  7. You should see a new tab with two windows, one of which contains the raw output from the profile
  8. Reproduce the issue. Make sure you have focused the pane running WSL, not the debug pane. You should see characters you type printed in red, like this: ␛[16;42;0;0;0;1_
  9. Reproduce the issue
    • Make sure you capture a working transaction and a broken one
  10. Send me the transcript of the debugging information (select, copy, paste into a .txt file or something)

This document will contain everything that came out of and went into the application. Since you changed your password (as suggested above), this shouldn't be an issue. If you'd be more comfortable, you can send it to me at the @microsoft.com address on my GitHub profile.

The debugger looks like this:
image

@DHowett commented on GitHub (Sep 18, 2020): Thanks for the info. I'm going to ask you to reproduce the issue with the the debug window enabled. **This will expose your password, so I suggest that you change your root password to one that can reproduce this bug but is not your actual password.** If you are willing to do that, follow the steps below. <details> <summary>How to capture debugging information</summary> 1. Edit your settings to add `"debugFeatures": true,` at the top (under the first `{`) 2. Open Terminal 3. Open the new tab dropdown 4. Hold down <kbd>Left Alt</kbd> and <kbd>Right Alt</kbd> at the same time 5. Launch the profile that you're having trouble with 6. Release <kbd>Alt</kbd>s 7. You should see a new tab with two windows, one of which contains the raw output from the profile 8. Reproduce the issue. Make sure you have focused the pane running WSL, not the debug pane. You should see characters you type printed in red, like this: `␛[16;42;0;0;0;1_` 9. Reproduce the issue * Make sure you capture a working transaction and a broken one 10. Send me the transcript of the debugging information (select, copy, paste into a .txt file or something) This document will contain everything that came out of _and went into_ the application. Since you changed your password (as suggested above), this shouldn't be an issue. If you'd be more comfortable, you can send it to me at the `@microsoft.com` address on my GitHub profile. The debugger looks like this: ![image](https://user-images.githubusercontent.com/189190/93539400-89300600-f905-11ea-8ea7-91c53cfb17d2.png) </details>
Author
Owner

@ghost commented on GitHub (Sep 22, 2020):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Sep 22, 2020): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#10456