starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Inconsistent output in standard console input and output when executing programs #14918

New Issue
Closed
opened 2026-01-31 04:23:10 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 04:23:10 +00:00
Owner
Copy Link

Originally created by @litesam on GitHub (Aug 20, 2021).

Windows Terminal version (or Windows build number)

Microsoft Windows [Version 10.0.19043.1165]

Other Software

vim 8.1.2269 (inside WSL2)

Steps to reproduce

I have a file named print_yes_if_even_else_no.py which should just run a test on the user inputted numbers and print yes if even and no if odd.
code for it:

tests = int(input())
for _ in range(tests):
    x = int(input())
    if x % 2 == 0:
        print('YES')
    else:
        print('NO')

Input to the code:

20
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

(copy paste it into the console on execution)

Expected Behavior

it should be printing each 'YES'/'NO' after its input
image

Actual Behavior

but it prints the result with weird line breaks.
image

Originally created by @litesam on GitHub (Aug 20, 2021). ### Windows Terminal version (or Windows build number) Microsoft Windows [Version 10.0.19043.1165] ### Other Software vim 8.1.2269 (inside WSL2) ### Steps to reproduce I have a file named `print_yes_if_even_else_no.py` which should just run a test on the user inputted numbers and print `yes` if even and `no` if odd. code for it: ```python tests = int(input()) for _ in range(tests): x = int(input()) if x % 2 == 0: print('YES') else: print('NO') ``` Input to the code: ``` 20 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ``` (copy paste it into the console on execution) ### Expected Behavior it should be printing each 'YES'/'NO' after its input ![image](https://user-images.githubusercontent.com/34811358/130225024-c2dc2792-9396-4f4f-9121-f8d589cb3c3d.png) ### Actual Behavior but it prints the result with weird line breaks. ![image](https://user-images.githubusercontent.com/34811358/130225220-45f9cac7-6394-4187-8853-901678b6a73e.png)
claunia added the Issue-QuestionNeeds-TriageNeeds-Tag-FixNeeds-Attention labels 2026-01-31 04:23:11 +00:00
claunia commented 2026-01-31 04:23:12 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 23, 2021):

Well, looks like this repros in both the Terminal and conhost, so it's not a Terminal-specific issue.

I'm not even sure this is an issue at all - it might be by design with the way python implements input(). It looks to me like they're echoing input as they get it (ENABLE_ECHO_INPUT). It just so happens that they're getting multiple lines of input before they're outputting any text.

Did this regress recently? Does this work as expected on other platforms/terminals (i.e. *nix with gnome-terminal or xterm)?

@zadjii-msft commented on GitHub (Aug 23, 2021): Well, looks like this repros in both the Terminal and conhost, so it's not a Terminal-specific issue. I'm not even sure this is an issue at all - it might be by design with the way python implements `input()`. It looks to me like they're echoing input as they get it ([`ENABLE_ECHO_INPUT`](https://docs.microsoft.com/en-us/windows/console/getconsolemode)). It just so happens that they're getting multiple lines of input before they're outputting any text. Did this regress recently? Does this work as expected on other platforms/terminals (i.e. *nix with `gnome-terminal` or `xterm`)?
claunia commented 2026-01-31 04:23:12 +00:00
Author
Owner
Copy Link

@litesam commented on GitHub (Aug 23, 2021):

Expected Behavior is the WSL2 but on a different terminal (WSLTTY).

Did this regress recently? Does this work as expected on other platforms/terminals (i.e. *nix with gnome-terminal or xterm)?

I found this issue like a week back, and was searching for a way to fix this before posting this as a issue.

@litesam commented on GitHub (Aug 23, 2021): Expected Behavior is the WSL2 but on a different terminal (WSLTTY). > Did this regress recently? Does this work as expected on other platforms/terminals (i.e. *nix with gnome-terminal or xterm)? I found this issue like a week back, and was searching for a way to fix this before posting this as a issue.
claunia commented 2026-01-31 04:23:12 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 23, 2021):

Can you try to see if the "expected" behavior occurs with the traditional Windows Console (if you run wsl directly?)

@DHowett commented on GitHub (Aug 23, 2021): Can you try to see if the "expected" behavior occurs with the traditional Windows Console (if you run wsl directly?)
claunia commented 2026-01-31 04:23:12 +00:00
Author
Owner
Copy Link

@litesam commented on GitHub (Aug 23, 2021):

This one is from the traditional Windows Console.
image

@litesam commented on GitHub (Aug 23, 2021): This one is from the traditional Windows Console. ![image](https://user-images.githubusercontent.com/34811358/130481833-ffd37662-380a-4e06-8b99-83a7dc2af48c.png)
claunia commented 2026-01-31 04:23:13 +00:00
Author
Owner
Copy Link

@litesam commented on GitHub (Aug 25, 2021):

Well, looks like this repros in both the Terminal and conhost, so it's not a Terminal-specific issue.

I'm not even sure this is an issue at all - it might be by design with the way python implements input(). It looks to me like they're echoing input as they get it (ENABLE_ECHO_INPUT). It just so happens that they're getting multiple lines of input before they're outputting any text.

Did this regress recently? Does this work as expected on other platforms/terminals (i.e. *nix with gnome-terminal or xterm)?

Could I disable the ENABLE_ECHO_INPUT in anyway or wait for the execution to finish before pasting the next value?

I also tried using sys.stdin.readline (both in python3 and python2) and I still get the same result:
image

This is from the GU (xterm) I installed to the same WSL2 client:
image
atleast the final result appears at the end once all the inputs are read in. Instead of the inconsistent ones in windows terminal, command prompt (bash).

(I can close the issue if there are no fixes for this)

@litesam commented on GitHub (Aug 25, 2021): > Well, looks like this repros in both the Terminal and conhost, so it's not a Terminal-specific issue. > > I'm not even sure this is an issue at all - it might be by design with the way python implements `input()`. It looks to me like they're echoing input as they get it ([`ENABLE_ECHO_INPUT`](https://docs.microsoft.com/en-us/windows/console/getconsolemode)). It just so happens that they're getting multiple lines of input before they're outputting any text. > > Did this regress recently? Does this work as expected on other platforms/terminals (i.e. *nix with `gnome-terminal` or `xterm`)? Could I disable the `ENABLE_ECHO_INPUT` in anyway or wait for the execution to finish before pasting the next value? I also tried using `sys.stdin.readline` (both in python3 and python2) and I still get the same result: ![image](https://user-images.githubusercontent.com/34811358/130768321-fdef6838-8f27-4da7-a696-5afaa1f61eb6.png) This is from the GU (xterm) I installed to the same WSL2 client: ![image](https://user-images.githubusercontent.com/34811358/131006775-fc5727c8-80f7-429d-b12d-f187d0c4daf5.png) atleast the final result appears at the end once all the inputs are read in. Instead of the inconsistent ones in windows terminal, command prompt (bash). (I can close the issue if there are no fixes for this)
claunia commented 2026-01-31 04:23:13 +00:00
Author
Owner
Copy Link

@litesam commented on GitHub (Aug 31, 2021):

@zadjii-msft could you check it on your machine too, if the issue is only on my device I can close this issue!

@litesam commented on GitHub (Aug 31, 2021): @zadjii-msft could you check it on your machine too, if the issue is only on my device I can close this issue!
claunia commented 2026-01-31 04:23:13 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 31, 2021):

Oh no, I'm sure that this repros on my machine - I just think it might be by design. I don't really have the time myself to get into investigating where in the stack this issue is occurring, or which set of console modes you could enable/disable to change this, sorry.

@zadjii-msft commented on GitHub (Aug 31, 2021): Oh no, I'm sure that this repros on my machine - I just think it might be by design. I don't really have the time myself to get into investigating where in the stack this issue is occurring, or which set of console modes you could enable/disable to change this, sorry.
claunia commented 2026-01-31 04:23:13 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 31, 2021):

The thing that sticks with me is that you're running python within WSL... so there's no console modes to worry about at all. 🤔

@DHowett commented on GitHub (Aug 31, 2021): The thing that sticks with me is that you're running python _within WSL_... so there's no console modes to worry about at all. 🤔
claunia commented 2026-01-31 04:23:14 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 31, 2021):

You know, if I had to guess it's that we don't "batch up" input when pasting. Terminal writes characters in as quickly as it can, in a single write, but they're transformed into "input records" (for Win32 console applications) . . . which are transformed back into input characters by WSL. There's some amount of buffering that happens inside WSL as it reads these input records and puts them into the emulated tty's input buffer.

This looks like it's by-design as far as Terminal/console is concerned; once we hand the records over to WSL they are in control over how big of a window size they read them with, and how they turn them into data on the PTY. That said, I somewhat wonder if we've been thinking about passthrough mode¹ too narrowly (only passing app output as unchanged as possible) . . . when it would also be a benefit for us to do "input" passthrough.

¹ A mode that gets buffering and translation out of the way.

@DHowett commented on GitHub (Aug 31, 2021): You know, if I had to guess it's that we don't "batch up" input when pasting. Terminal writes characters in as quickly as it can, in a single write, but they're transformed into "input records" (for Win32 console applications) . . . which are transformed back into input characters by WSL. There's some amount of buffering that happens inside WSL as it reads these input records and puts them into the emulated tty's input buffer. This looks like it's by-design as far as Terminal/console is concerned; once we hand the records over to WSL they are in control over how big of a window size they read them with, and how they turn them into data on the PTY. That said, I somewhat wonder if we've been thinking about passthrough mode¹ too narrowly (only passing app output as unchanged as possible) . . . when it would also be a benefit for us to do "input" passthrough. ¹ A mode that gets buffering and translation out of the way.
claunia commented 2026-01-31 04:23:14 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 31, 2021):

(Diagrammed; may make it clearer; may not!)

image

@DHowett commented on GitHub (Aug 31, 2021): (Diagrammed; may make it clearer; may not!) ![image](https://user-images.githubusercontent.com/189190/131569624-e42e5258-0300-4cf2-9e39-7752829424e6.png)
claunia commented 2026-01-31 04:23:14 +00:00
Author
Owner
Copy Link

@litesam commented on GitHub (Sep 1, 2021):

I created a remote desktop connection (with the same WSL) and opened a gnome terminal in that interface and did the same on it refer to 2nd screenshot in this comment that works without the output being overlapped to the input... So I think the issue is not with the WSL @DHowett. (or I might be misunderstanding about this)

@litesam commented on GitHub (Sep 1, 2021): I created a remote desktop connection (with the same WSL) and opened a gnome terminal in that interface and did the same on it [refer to 2nd screenshot in this comment](https://github.com/microsoft/terminal/issues/10994#issuecomment-905260499) that works without the output being overlapped to the input... So I think the issue is not with the WSL @DHowett. (or I might be misunderstanding about this)
claunia commented 2026-01-31 04:23:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 7, 2022):

So I think the issue is not with the WSL

Actually, I'm pretty sure this is an issue with lxtty. Your repro with gnome-terminal probably just took lxtty out of the equation. I'd file this upstream on https://github.com/microsoft/WSL

@zadjii-msft commented on GitHub (Nov 7, 2022): > So I think the issue is not with the WSL Actually, I'm pretty sure this _is_ an issue with lxtty. Your repro with gnome-terminal probably just took lxtty out of the equation. I'd file this upstream on https://github.com/microsoft/WSL
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Question Needs-Attention Needs-Tag-Fix Needs-Triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#14918
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?