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

Git output oddly indented and sometimes causing crash with TERM=msys #13866

New Issue
Closed
opened 2026-01-31 03:54:20 +00:00 by claunia · 11 comments
claunia commented 2026-01-31 03:54:20 +00:00
Owner
Copy Link

Originally created by @poke on GitHub (May 22, 2021).

Windows Terminal version (or Windows build number)

1.7.1033.0

Other Software

Using Git for Windows version 2.31.1.windows.1 with the bundled vim v8.2.1895 with PowerShell 5.1.19041.906.

Steps to reproduce

In a new folder, enter the following commands after another:

PS C:\TerminalIssueRepro> $env:TERM = 'msys'
PS C:\TerminalIssueRepro> git init
PS C:\TerminalIssueRepro> 'bin/' > .gitignore
PS C:\TerminalIssueRepro> git add .\.gitignore
PS C:\TerminalIssueRepro> git commit

vim opens to prompt for a commit message, so enter something there, save and exit.

Expected Behavior

The console window should look like this:

PS C:\TerminalIssueRepro> git init
Initialized empty Git repository in C:/TerminalIssueRepro/.git/
PS C:\TerminalIssueRepro> 'bin/' > .gitignore
PS C:\TerminalIssueRepro> git add .\.gitignore
PS C:\TerminalIssueRepro> git commit
[main (root-commit) abe2cba] Initialize
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
PS C:\TerminalIssueRepro>

Actual Behavior

Instead, due to the TERM=msys, the output looks like this:

PS C:\TerminalIssueRepro> git init
Initialized empty Git repository in C:/TerminalIssueRepro/.git/
PS C:\TerminalIssueRepro> 'bin/' > .gitignore
PS C:\TerminalIssueRepro> git add .\.gitignore
PS C:\TerminalIssueRepro> git commit
[main (root-commit) abe2cba] Initialize
                                        1 file changed, 0 insertions(+), 0 deletions(-)
                                                                                        create mode 100644 .gitignore

This can be reproduced by re-triggering vim for editing, e.g. using git commit --amend. Sometimes, the terminal process completely crashes after closing vim, e.g. with this output:

PS C:\TerminalIssueRepro> git commit --amend
[main 27a142f] Initialize
                          Date: Sat May 22 14:20:41 2021 +0200
                                                               1 file changed, 0 insertions(+), 0 deletions(-)
                                                                                                               create mode 100644 .gitignore
[Verarbeitung des Prozesses mit Code 5 beendet]

(Eror message says “Processing of process ended with code 5”)

If I switch to the TERM mode cygwin (the default I believe?), then the output will look ok in that there is no odd indentation and the process won’t crash. However doing so means that after exiting vim, the screen will be completely blank above the generated output, i.e. the vim process blanks the previous console output.

In ConEmu, using TERM=msys works without any problems, so does it in the native PowerShell host or cmd.exe.

Originally created by @poke on GitHub (May 22, 2021). ### Windows Terminal version (or Windows build number) 1.7.1033.0 ### Other Software Using Git for Windows version 2.31.1.windows.1 with the bundled vim v8.2.1895 with PowerShell 5.1.19041.906. ### Steps to reproduce In a new folder, enter the following commands after another: ``` PS C:\TerminalIssueRepro> $env:TERM = 'msys' PS C:\TerminalIssueRepro> git init PS C:\TerminalIssueRepro> 'bin/' > .gitignore PS C:\TerminalIssueRepro> git add .\.gitignore PS C:\TerminalIssueRepro> git commit ``` vim opens to prompt for a commit message, so enter something there, save and exit. ### Expected Behavior The console window should look like this: ``` PS C:\TerminalIssueRepro> git init Initialized empty Git repository in C:/TerminalIssueRepro/.git/ PS C:\TerminalIssueRepro> 'bin/' > .gitignore PS C:\TerminalIssueRepro> git add .\.gitignore PS C:\TerminalIssueRepro> git commit [main (root-commit) abe2cba] Initialize 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 .gitignore PS C:\TerminalIssueRepro> ``` ### Actual Behavior Instead, due to the TERM=msys, the output looks like this: ``` PS C:\TerminalIssueRepro> git init Initialized empty Git repository in C:/TerminalIssueRepro/.git/ PS C:\TerminalIssueRepro> 'bin/' > .gitignore PS C:\TerminalIssueRepro> git add .\.gitignore PS C:\TerminalIssueRepro> git commit [main (root-commit) abe2cba] Initialize 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 .gitignore ``` This can be reproduced by re-triggering vim for editing, e.g. using `git commit --amend`. Sometimes, the terminal process completely crashes after closing vim, e.g. with this output: ``` PS C:\TerminalIssueRepro> git commit --amend [main 27a142f] Initialize Date: Sat May 22 14:20:41 2021 +0200 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 .gitignore [Verarbeitung des Prozesses mit Code 5 beendet] ``` (Eror message says _“Processing of process ended with code 5”_) If I switch to the `TERM` mode `cygwin` (the default I believe?), then the output will look *ok* in that there is no odd indentation and the process won’t crash. However doing so means that after exiting vim, the screen will be completely blank above the generated output, i.e. the vim process blanks the previous console output. In ConEmu, using TERM=msys works without any problems, so does it in the native PowerShell host or cmd.exe.
claunia added the Area-OutputResolution-Duplicate labels 2026-01-31 03:54:20 +00:00
claunia commented 2026-01-31 03:54:21 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 27, 2021):

This is fascinating.

/feedback

@DHowett commented on GitHub (May 27, 2021): This is _fascinating_. /feedback
claunia commented 2026-01-31 03:54:21 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 27, 2021):

Hi there!

Can you please send us feedback with the Feedback Hub with this issue and paste the link here so we can more easily find your crash information on the back end?

Thanks!

image image

@ghost commented on GitHub (May 27, 2021): Hi there!<br><br>Can you please send us feedback with the Feedback Hub with this issue and paste the link here so we can more easily find your crash information on the back end?<br><br>Thanks!<br><br>![image](https://user-images.githubusercontent.com/18221333/62478757-b69d0d00-b760-11e9-9626-1fa33c91e7c5.png) ![image](https://user-images.githubusercontent.com/18221333/62478649-6de55400-b760-11e9-806e-5aab7e085a9f.png)
claunia commented 2026-01-31 03:54:22 +00:00
Author
Owner
Copy Link

@poke commented on GitHub (May 28, 2021):

I unfortunately cannot use the Feedback hub on this machine since my domain policies prevent me from changing the data privacy settings that are required to use it… I can try to replicate this during the weekend on a different computer.

For what it’s worth, I couldn’t replicate the crash just now (of course not… 🙄) but here you have a screenshot of the funny output:

Screenshot of the oddly indented output

@poke commented on GitHub (May 28, 2021): I unfortunately cannot use the Feedback hub on this machine since my domain policies prevent me from changing the data privacy settings that are required to use it… I can try to replicate this during the weekend on a different computer. For what it’s worth, I couldn’t replicate the crash just now (of course not… 🙄) but here you have a screenshot of the funny output: ![Screenshot of the oddly indented output](https://user-images.githubusercontent.com/132240/119953435-49461600-bf9e-11eb-9d81-e0db2d537e4d.png)
claunia commented 2026-01-31 03:54:22 +00:00
Author
Owner
Copy Link

@carenas commented on GitHub (Sep 6, 2021):

interestingly; observing the odd formatting issue also but using the default TERM=xterm-color (or xterm) and a git bash tab, I also don't see the problem if using git bash directly (hence mintty) or the regular console (cmd or powershell)

TERM=cygwin workarounds the problem, and the issue can be seen in both the release and preview versions of Windows Terminal

UPDATE: built a custom git version to debug the formatting, and it would seem to be a residual misconfiguration of the terminal after vim closes, if using a different EDITOR for commit message the problem is not reproducible either regardless of TERM

@carenas commented on GitHub (Sep 6, 2021): interestingly; observing the odd formatting issue also but using the default TERM=xterm-color (or xterm) and a git bash tab, I also don't see the problem if using git bash directly (hence mintty) or the regular console (cmd or powershell) TERM=cygwin workarounds the problem, and the issue can be seen in both the release and preview versions of Windows Terminal UPDATE: built a custom git version to debug the formatting, and it would seem to be a residual misconfiguration of the terminal after vim closes, if using a different EDITOR for commit message the problem is not reproducible either regardless of TERM
claunia commented 2026-01-31 03:54:22 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 7, 2021):

Wait so, after your update I'm not entirely clear what the state of this is. Did this go away with a updated git version? If not, then I'd be interested in the diff between the infocmp for xterm-color, cygwin, and ansi.

WAIT is this vim.exe, or a vim that ships with msys/cygwin?

@zadjii-msft commented on GitHub (Sep 7, 2021): Wait so, after your update I'm not entirely clear what the state of this is. Did this go away with a updated git version? If not, then I'd be interested in the diff between the `infocmp` for `xterm-color`, `cygwin`, and `ansi`. WAIT is this `vim.exe`, or a `vim` that ships with msys/cygwin?
claunia commented 2026-01-31 03:54:22 +00:00
Author
Owner
Copy Link

@carenas commented on GitHub (Sep 7, 2021):

Wait so, after your update I'm not entirely clear what the state of this is. Did this go away with a updated git version?

no, but it could be handled there even if we don't have yet the facilities to do so.

If not, then I'd be interested in the diff between the infocmp for xterm-color, cygwin, and ansi.

git for windows doesn't have ansi on its terminfo, but xterm-256color and cygwin diff in:

https://pastebin.com/y4pwLZ1D

WAIT is this vim.exe, or a vim that ships with msys/cygwin?

msys vim, which comes with git for windows and is invoked by default through a shell script in the emulated POSIX tree as /usr/bin/vi

you can reproduce it locally by installing git for windows[1] and running the git bash integration with windows terminal AS-IS.

[1] https://gitforwindows.org/

@carenas commented on GitHub (Sep 7, 2021): > Wait so, after your update I'm not entirely clear what the state of this is. Did this go away with a updated git version? no, but it could be handled there even if we don't have yet the facilities to do so. > If not, then I'd be interested in the diff between the `infocmp` for `xterm-color`, `cygwin`, and `ansi`. git for windows doesn't have ansi on its terminfo, but xterm-256color and cygwin diff in: https://pastebin.com/y4pwLZ1D > WAIT is this `vim.exe`, or a `vim` that ships with msys/cygwin? msys vim, which comes with git for windows and is invoked by default through a shell script in the emulated POSIX tree as /usr/bin/vi you can reproduce it locally by installing git for windows[1] and running the git bash integration with windows terminal AS-IS. [1] https://gitforwindows.org/
claunia commented 2026-01-31 03:54:22 +00:00
Author
Owner
Copy Link

@reece-bennett commented on GitHub (Sep 11, 2021):

I'm not seeing any crashes but am experiencing the misaligned output.

I'm on git version 2.32.0.windows.2 and using vim as my editor (the default one that comes bundled with Git for Windows).

Everything looks fine in mintty that Git for Windows installs:

git-bash

But in Windows Terminal I get the odd output (also happening for me in VSCode terminal):

windows-terminal

@reece-bennett commented on GitHub (Sep 11, 2021): I'm not seeing any crashes but am experiencing the misaligned output. I'm on git version 2.32.0.windows.2 and using vim as my editor (the default one that comes bundled with Git for Windows). Everything looks fine in mintty that Git for Windows installs: ![git-bash](https://user-images.githubusercontent.com/6674785/132948776-8b2f465d-a11c-473e-bd84-10cf7eee063c.png) But in Windows Terminal I get the odd output (also happening for me in VSCode terminal): ![windows-terminal](https://user-images.githubusercontent.com/6674785/132948796-6e74ee57-ab7a-4e9d-9778-ad569e8b5df7.png)
claunia commented 2026-01-31 03:54:23 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 15, 2021):

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 15, 2021): 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**.
claunia commented 2026-01-31 03:54:23 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 15, 2021):

You know, we've got the same exact thing going on over in #9359, so I[m gonna close this as a dupe an put all the discussion in one place. Thanks! /dup #9359

@zadjii-msft commented on GitHub (Sep 15, 2021): You know, we've got the same exact thing going on over in #9359, so I[m gonna close this as a dupe an put all the discussion in one place. Thanks! /dup #9359
claunia commented 2026-01-31 03:54:23 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 15, 2021):

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 commented on GitHub (Sep 15, 2021): 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!
claunia commented 2026-01-31 03:54:24 +00:00
Author
Owner
Copy Link

@carenas commented on GitHub (Oct 2, 2021):

Did this go away with a updated git version?

Yes and no; I coded a branch with the facility that was missing in git to be able to handle this terminal corruption, and I am able to solve the endemic problem that was reported here and in other related tickets.

WAIT is this vim.exe, or a vim that ships with msys/cygwin?

vim is using an msys pty, while git is using a conio (hence conPTY when supported), but IMHO that configuration should work and it almost does (vi is able to change the terminal settings and control its screen and almost return it back clean); the only missing flag that is evident would seem to be "onlcr" and my code fixes that part by clearing that missing DISABLE_NEWLINE_AUTO_RETURN after vim exit.

BUT if I kill vim forcefully, there are a lot more flags that are not set correctly and EVEN if I am writing back the same conio flags from before vim was spawned, the terminal is still missing onlcr and shows the indented output, therefore still requiring a reset.

@carenas commented on GitHub (Oct 2, 2021): > Did this go away with a updated git version? Yes and no; I coded a [branch](/carenas/git/tree/terminal-stack) with the facility that was missing in git to be able to handle this terminal corruption, and I am able to solve the endemic problem that was reported here and in other related tickets. > WAIT is this `vim.exe`, or a `vim` that ships with msys/cygwin? vim is using an msys pty, while git is using a conio (hence conPTY when supported), but IMHO that configuration should work and it almost does (vi is able to change the terminal settings and control its screen and almost return it back clean); the only missing flag that is evident would seem to be "onlcr" and my code fixes that part by clearing that missing DISABLE_NEWLINE_AUTO_RETURN after vim exit. BUT if I kill vim forcefully, there are a lot more flags that are not set correctly and EVEN if I am writing back the same conio flags from before vim was spawned, the terminal is still missing onlcr and shows the indented output, therefore still requiring a `reset`.
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-Output Resolution-Duplicate
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#13866
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?