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

Windows 10 1809 Buffer issues with VSCode (windows ver) #494

New Issue
Closed
opened 2026-01-30 21:53:40 +00:00 by claunia · 3 comments
claunia commented 2026-01-30 21:53:40 +00:00
Owner
Copy Link

Originally created by @weikinhuang on GitHub (Dec 28, 2018).

After upgrading to W10 1809, I'm having issues running VSCode (the windows version) from the WSL terminal via code commands.

I reported the issue here: https://github.com/Microsoft/vscode/issues/63539

However after some additional testing, I've discovered it might be a issue with WSL instead of vscode.

  • Your Windows build number: (Type ver at a Windows Command Prompt)
Microsoft Windows [Version 10.0.18305.1003]

Copying from the other issue

Seems there might be some weird issue with the shell or something with the stdout buffer in the current version of wsl or ELECTRON_RUN_AS_NODE.

Note: I run this under a fresh install of Windows 10 1809 in a VM and a fresh install of WSL Ubuntu, and the VSCode x64 User Installer.

I ran vscode --version in the Ubuntu app shell and got this output with weird spacing:

$ code --version
1.30.1
      dea8705087adb1b5e5ae1d9123278e178656186a
                                              x64

Then I tried again with a cat to buffer the output, and it printed out fine:

$ code --version | cat
1.30.1
dea8705087adb1b5e5ae1d9123278e178656186a
x64

In the case where I opened the issue, I was running the shell via SSH and using a local ssh terminal emulator (SecureCrt):

$ code --version
--- NO OUTPUT ---

However if I use cat as I did above, it works just fine:

code --version | cat -           
1.30.1
dea8705087adb1b5e5ae1d9123278e178656186a
x64

This also solves the issue where I don't regain control of the terminal when I run code ., if I pipe it through code . | cat -, it works perfectly like it used to.

Originally created by @weikinhuang on GitHub (Dec 28, 2018). After upgrading to W10 1809, I'm having issues running VSCode (the windows version) from the WSL terminal via `code` commands. I reported the issue here: https://github.com/Microsoft/vscode/issues/63539 However after some additional testing, I've discovered it might be a issue with WSL instead of vscode. * Your Windows build number: (Type `ver` at a Windows Command Prompt) ``` Microsoft Windows [Version 10.0.18305.1003] ``` **Copying from the other issue** Seems there might be some weird issue with the shell or something with the stdout buffer in the current version of wsl or ELECTRON_RUN_AS_NODE. Note: I run this under a fresh install of Windows 10 1809 in a VM and a fresh install of WSL Ubuntu, and the VSCode x64 User Installer. I ran `vscode --version` in the `Ubuntu` app shell and got this output with weird spacing: ```bash $ code --version 1.30.1 dea8705087adb1b5e5ae1d9123278e178656186a x64 ``` Then I tried again with a cat to buffer the output, and it printed out fine: ```bash $ code --version | cat 1.30.1 dea8705087adb1b5e5ae1d9123278e178656186a x64 ``` In the case where I opened the issue, I was running the shell via SSH and using a local ssh terminal emulator (`SecureCrt`): ```bash $ code --version --- NO OUTPUT --- ``` However if I use `cat` as I did above, it works just fine: ```bash code --version | cat - 1.30.1 dea8705087adb1b5e5ae1d9123278e178656186a x64 ``` This also solves the issue where I don't regain control of the terminal when I run `code .`, if I pipe it through `code . | cat -`, it works perfectly like it used to.
claunia commented 2026-01-30 21:53:41 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Dec 28, 2018):

@bitcrazed Is there a chance you can transfer this to Microsoft/WSL? It looks like an interop issue, not a Console issue.

@DHowett-MSFT commented on GitHub (Dec 28, 2018): @bitcrazed Is there a chance you can transfer this to Microsoft/WSL? It looks like an interop issue, not a Console issue.
claunia commented 2026-01-30 21:53:42 +00:00
Author
Owner
Copy Link

@weikinhuang commented on GitHub (Dec 28, 2018):

I'll close this and open it there @DHowett-MSFT

@weikinhuang commented on GitHub (Dec 28, 2018): I'll close this and open it there @DHowett-MSFT
claunia commented 2026-01-30 21:53:42 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Dec 28, 2018):

@weikinhuang thank you!

@DHowett-MSFT commented on GitHub (Dec 28, 2018): @weikinhuang thank you!
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
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#494
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?