Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

issue with control characters appearing in command window #7126

Closed
manbearian opened this issue Jul 30, 2020 · 6 comments
Closed

issue with control characters appearing in command window #7126

manbearian opened this issue Jul 30, 2020 · 6 comments
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@manbearian
Copy link

suddenly my command window starting show control characters instead of doing the actions (e.g. image shows pushing the up arrow on the keyboard and then the down arrow). Other shells/tabs in the same terminal window don't have this issue.

image

Unfortunately i don't have a repro, and i don't know how i got into this state. I have a DMP of WIndowsTerminal.exe if that helps.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jul 30, 2020
@DHowett
Copy link
Member

DHowett commented Jul 30, 2020

So, this is usually caused by an application leaving ENABLE_VIRTUAL_TERMINAL_INPUT enabled when it exits. The input state is, unfortunately, global for a given console session (in Terminal, that's the tree of processes under one terminal pane)... which means applications can trivially mess with eachother like this.

@manbearian
Copy link
Author

thanks for the quick response; is there an manual fix i can run? i'd love to save this terminal session :)

@DHowett
Copy link
Member

DHowett commented Jul 30, 2020

Hmm.. so, if you just run powershell and then exit it, it should restore the input mode. I just gave that a shot over here.

@manbearian
Copy link
Author

Btw, now that i can get my history for that shell, i believe that the culprit is vi. the last few previous commands were git diff invocations.

@DHowett
Copy link
Member

DHowett commented Jul 30, 2020

Thanks for that! Yeah, it'll do that sometimes. Sorry 😄

For this one, by-design is appropriate, even though that's a little unfortunate. We're kicking around the idea of making the input mode per-process state, but our input queue is appalling right now. I tried to hack this up for hackathon!

/dup #4954

@ghost
Copy link

ghost commented Jul 30, 2020

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost closed this as completed Jul 30, 2020
@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jul 30, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

2 participants