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

npm install of cmake-js fails with '...ith ANSI escape codes #1395

New Issue
Closed
opened 2026-01-30 22:24:41 +00:00 by claunia · 5 comments
claunia commented 2026-01-30 22:24:41 +00:00
Owner
Copy Link

Originally created by @rkeithhill on GitHub (May 28, 2019).

Environment

Windows build number: 1903 18362.116
Windows Terminal version (if applicable): Build from Saturday, May 25th

Any other software? PowerShell Core 6.2.0 / ssh

Steps to reproduce

  1. ssh'd (using Windows OpenSSH client v7.7.2.1) to a Windows 10 machine running 1809. SSH user runs as admin on that box.
  2. Run npm install -g cmake-js

Expected behavior

No errors. Which is what I get if I ssh from a regular PowerShell Core (conhsot) console.

Actual behavior

Errors with:

PS> npm install -g cmake-js                                                                              
npm ERR! Unexpected end of JSON input while parsing near '...ith ANSI escape codes' 
npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\mctcbld\AppData\Roaming\npm-cache\_logs\2019-05-28T21_42_46_235Z-debug.log

The last (failing) part of the npm log is:

430 silly pacote range manifest for strip-ansi@^3.0.1 fetched in 541ms
431 silly resolveWithNewModule strip-ansi@3.0.1 checking installable status
432 timing stage:rollbackFailedOptional Completed in 1ms
433 timing stage:runTopLevelLifecycles Completed in 34700ms
434 verbose stack SyntaxError: Unexpected end of JSON input while parsing near '...ith ANSI escape codes'
434 verbose stack     at JSON.parse (<anonymous>)
434 verbose stack     at parseJson (C:\Users\mctcbld\AppData\Roaming\npm\node_modules\npm\node_modules\json-parse-better
-errors\index.js:7:17)
434 verbose stack     at consumeBody.call.then.buffer (C:\Users\mctcbld\AppData\Roaming\npm\node_modules\npm\node_module
s\node-fetch-npm\src\body.js:96:50)
434 verbose stack     at <anonymous>
434 verbose stack     at process._tickCallback (internal/process/next_tick.js:188:7)
435 verbose cwd C:\Users\mctcbld
436 verbose Windows_NT 10.0.17763
437 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\mctcbld\\AppData\\Roaming\\npm\\node_modules\\npm\\bi
n\\npm-cli.js" "install" "-g" "cmake-js" "-f"
438 verbose node v8.11.4
439 verbose npm  v6.4.0
440 error Unexpected end of JSON input while parsing near '...ith ANSI escape codes'
441 verbose exit [ 1, true ]

I wouldn't normally think this a problem with Terminal except for the mention of "ANSI escape codes" and the fact that the install works in a regular console.

Originally created by @rkeithhill on GitHub (May 28, 2019). <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: 1903 18362.116 Windows Terminal version (if applicable): Build from Saturday, May 25th Any other software? PowerShell Core 6.2.0 / ssh ``` # Steps to reproduce 1. ssh'd (using Windows OpenSSH client v7.7.2.1) to a Windows 10 machine running 1809. SSH user runs as admin on that box. 2. Run `npm install -g cmake-js` # Expected behavior No errors. Which is what I get if I ssh from a regular PowerShell Core (conhsot) console. # Actual behavior Errors with: ``` PS> npm install -g cmake-js npm ERR! Unexpected end of JSON input while parsing near '...ith ANSI escape codes' npm ERR! A complete log of this run can be found in: npm ERR! C:\Users\mctcbld\AppData\Roaming\npm-cache\_logs\2019-05-28T21_42_46_235Z-debug.log ``` The last (failing) part of the npm log is: ``` 430 silly pacote range manifest for strip-ansi@^3.0.1 fetched in 541ms 431 silly resolveWithNewModule strip-ansi@3.0.1 checking installable status 432 timing stage:rollbackFailedOptional Completed in 1ms 433 timing stage:runTopLevelLifecycles Completed in 34700ms 434 verbose stack SyntaxError: Unexpected end of JSON input while parsing near '...ith ANSI escape codes' 434 verbose stack at JSON.parse (<anonymous>) 434 verbose stack at parseJson (C:\Users\mctcbld\AppData\Roaming\npm\node_modules\npm\node_modules\json-parse-better -errors\index.js:7:17) 434 verbose stack at consumeBody.call.then.buffer (C:\Users\mctcbld\AppData\Roaming\npm\node_modules\npm\node_module s\node-fetch-npm\src\body.js:96:50) 434 verbose stack at <anonymous> 434 verbose stack at process._tickCallback (internal/process/next_tick.js:188:7) 435 verbose cwd C:\Users\mctcbld 436 verbose Windows_NT 10.0.17763 437 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\mctcbld\\AppData\\Roaming\\npm\\node_modules\\npm\\bi n\\npm-cli.js" "install" "-g" "cmake-js" "-f" 438 verbose node v8.11.4 439 verbose npm v6.4.0 440 error Unexpected end of JSON input while parsing near '...ith ANSI escape codes' 441 verbose exit [ 1, true ] ``` I wouldn't normally think this a problem with Terminal except for the mention of "ANSI escape codes" and the fact that the install works in a regular console.
claunia added the Issue-BugArea-VTResolution-ExternalProduct-Meta labels 2026-01-30 22:24:41 +00:00
claunia commented 2026-01-30 22:24:42 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 29, 2019):

I cannot possibly image a scenario where the Windows Terminal is somehow breaking this, but hey I've been wrong before.

Could you try something crazy for me? Could you try launching a normal conhost window, then running wsl (any distro will do), then from wsl, launching cmd.exe, and running ssh as you normally do? This will make sure cmd (and ssh) are running attached to a conpty, similar to how the Windows Terminal works.

If that works, then I'll be extra shocked that this is broken due to Windows Terminal

@zadjii-msft commented on GitHub (May 29, 2019): I cannot possibly image a scenario where the Windows Terminal is somehow breaking this, but hey I've been wrong before. Could you try something crazy for me? Could you try launching a normal conhost window, then running wsl (any distro will do), then from wsl, launching cmd.exe, and running ssh as you normally do? This will make sure cmd (and ssh) are running attached to a conpty, similar to how the Windows Terminal works. If that works, then I'll be extra shocked that this is broken due to Windows Terminal
claunia commented 2026-01-30 22:24:43 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 29, 2019):

Here's what I get:

pwsh in conhost

image

pwsh over conpty (WSL interop)

image

pwsh in Windows Terminal

image

@DHowett-MSFT commented on GitHub (May 29, 2019): Here's what I get: ### pwsh in conhost ![image](https://user-images.githubusercontent.com/14316954/58576464-41a9d600-81f9-11e9-8e18-dae2a12721f1.png) ### pwsh over conpty (WSL interop) ![image](https://user-images.githubusercontent.com/14316954/58576467-44a4c680-81f9-11e9-8662-4721ebf7c49e.png) ### pwsh in Windows Terminal ![image](https://user-images.githubusercontent.com/14316954/58576476-49697a80-81f9-11e9-9f1a-3de11579c948.png)
claunia commented 2026-01-30 22:24:43 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 29, 2019):

Ah, and here's what I get over ssh:

image

@DHowett-MSFT commented on GitHub (May 29, 2019): Ah, and here's what I get over ssh: ![image](https://user-images.githubusercontent.com/14316954/58576888-2a1f1d00-81fa-11e9-988a-73c567b721ff.png)
claunia commented 2026-01-30 22:24:44 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (May 29, 2019):

using Windows OpenSSH client v7.7.2.1

May not make a difference in this realm but have you tried updating to 7.9? You'll want to upgrade it anyways even if it makes no difference here.

@WSLUser commented on GitHub (May 29, 2019): > using Windows OpenSSH client v7.7.2.1 May not make a difference in this realm but have you tried updating to 7.9? You'll want to upgrade it anyways even if it makes no difference here.
claunia commented 2026-01-30 22:24:44 +00:00
Author
Owner
Copy Link

@rkeithhill commented on GitHub (May 29, 2019):

Not sure what was going on yesterday but I've tried several machines now and I can't repro this. Going to close this issue but if I see it again, I'll let you know.

@rkeithhill commented on GitHub (May 29, 2019): Not sure what was going on yesterday but I've tried several machines now and I can't repro this. Going to close this issue but if I see it again, I'll let you know.
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 Area-VT Issue-Bug Product-Meta Resolution-External
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#1395
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?