git bash for windows in terminal does not break lines correctly #12842

@RedX2501 commented on GitHub (Mar 4, 2021):

Forgot to mention I saw this on preview. I have not checked on the "official" version yet. I have added the version number to the post above.

@RedX2501 commented on GitHub (Mar 4, 2021): Forgot to mention I saw this on preview. I have not checked on the "official" version yet. I have added the version number to the post above.

claunia commented

@RedX2501 commented on GitHub (Mar 4, 2021):

I also see this in the official version

Windows Terminal
Version: 1.6.10571.0

$git rebase -i develop
Successfully rebased and updated refs/heads/testing.
                                                    myPc /c/data/sw testing

@RedX2501 commented on GitHub (Mar 4, 2021): I also see this in the official version ``` Windows Terminal Version: 1.6.10571.0 ``` ``` $git rebase -i develop Successfully rebased and updated refs/heads/testing. myPc /c/data/sw testing ```

claunia commented

@RedX2501 commented on GitHub (Mar 5, 2021):

Today this led to a buffer overrun exception:

@RedX2501 commented on GitHub (Mar 5, 2021): Today this led to a buffer overrun exception: ![image001](https://user-images.githubusercontent.com/929932/110089418-6354cb80-7d96-11eb-8544-22c30c4a3a35.png)

claunia commented

@zadjii-msft commented on GitHub (Mar 5, 2021):

Well that's super weird. I don't think that's necessarily caused by the same thing that's causing the \r to get dropped here. We've seen that before in #7763, but that had more to do with resizing the buffer with DBCS characters in it, and presumably that's not happening in this case.

If that happens again, can you use task manager to capture a dump file of Terminal when that dialog pops up?

@zadjii-msft commented on GitHub (Mar 5, 2021): Well that's super weird. I don't think that's necessarily caused by the same thing that's causing the `\r` to get dropped here. We've seen that before in #7763, but that had more to do with resizing the buffer with DBCS characters in it, and presumably that's not happening in this case. If that happens again, can you use task manager to capture a dump file of Terminal when that dialog pops up?

claunia commented

@ffes commented on GitHub (Jul 9, 2021):

I see this behavior with every git commit I do. Other git subcommands seem to work for me, though I haven't used rebase recently. Never ran into the buffer overrun, mentioned above.

FYI:
Windows Terminal Preview Version: 1.9.1523.0
git version 2.31.1.windows.1

@ffes commented on GitHub (Jul 9, 2021): I see this behavior with every `git commit` I do. Other git subcommands seem to work for me, though I haven't used `rebase` recently. Never ran into the buffer overrun, mentioned above. FYI: Windows Terminal Preview Version: 1.9.1523.0 git version 2.31.1.windows.1

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Jul 10, 2021):

Does stty onlcr help?

@KalleOlaviNiemitalo commented on GitHub (Jul 10, 2021): Does `stty onlcr` help?

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Jul 10, 2021):

Regarding the error message:

The system detected an overrun of a stack-based buffer in the application. This overrun could potentially allow a malicious user to gain control of this application.

As described in STATUS_STACK_BUFFER_OVERRUN doesn’t mean that there was a stack buffer overrun, the same exception code is nowadays used for other purposes too. I don't know whether Windows nowadays bothers to check the fast-fail code before it pops up the message box with this wording.

@KalleOlaviNiemitalo commented on GitHub (Jul 10, 2021): Regarding the error message: > The system detected an overrun of a stack-based buffer in the application. This overrun could potentially allow a malicious user to gain control of this application. As described in [STATUS_STACK_BUFFER_OVERRUN doesn’t mean that there was a stack buffer overrun](<https://devblogs.microsoft.com/oldnewthing/20190108-00/?p=100655>), the same exception code is nowadays used for other purposes too. I don't know whether Windows nowadays bothers to check the fast-fail code before it pops up the message box with this wording.

claunia commented

@poke commented on GitHub (Sep 16, 2021):

To add what we know from the other issue #10152, can you check your TERM environment variable when you experience the formatting issue or even the crash? In my situation, it depends on what value it has. Apparently, Git Bash defaults to xterm, and I personally hit these issues with the value msys when using PowerShell.

Terminal definitely behaves different here from other console emulators like the default conhost, mintty or ConEmu.

@poke commented on GitHub (Sep 16, 2021): To add what we know from the other issue #10152, can you check your TERM environment variable when you experience the formatting issue or even the crash? In my situation, it depends on what value it has. Apparently, Git Bash defaults to `xterm`, and I personally hit these issues with the value `msys` when using PowerShell. Terminal definitely behaves different here from other console emulators like the default conhost, mintty or ConEmu.

claunia commented

@ffes commented on GitHub (Sep 20, 2021):

In my case in Windows Terminal Preview v1.11.2421.0:

$ echo $TERM
xterm-256color

When I run "Git Bash" from the Start Menu (which uses mintty):

$ echo $TERM
xterm

@ffes commented on GitHub (Sep 20, 2021): In my case in Windows Terminal Preview v1.11.2421.0: ```bash $ echo $TERM xterm-256color ``` When I run "Git Bash" from the Start Menu (which uses mintty): ```bash $ echo $TERM xterm ```

claunia commented

@RedX2501 commented on GitHub (Sep 30, 2021):

Both are xterm-256color for me.

@RedX2501 commented on GitHub (Sep 30, 2021): Both are `xterm-256color` for me.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Sep 30, 2021):

How about the stty command?

On Linux, Git would output just a LF, the Linux tty driver would convert that to CR LF, and the terminal would move the cursor to the start of the line on CR and then to the next line on LF. This behaviour of the terminal driver can be enabled or disabled with the ONLCR flag in the tcsetattr function, or with the stty program.

On Windows, the console host does not convert LF to CR LF, so I assume this is instead done by some emulation layer in the Git for Windows package. If the emulated ONLCR flag has become turned off (e.g. because an editor such as vi turned it off and then was killed before it was able to turn the flag back on), that could cause the symptom described here. In this situation, stty onlcr or stty sane would turn the flag back on and make the output look OK again.

@KalleOlaviNiemitalo commented on GitHub (Sep 30, 2021): How about the `stty` command? On Linux, Git would output just a LF, the Linux tty driver would convert that to CR LF, and the terminal would move the cursor to the start of the line on CR and then to the next line on LF. This behaviour of the terminal driver can be enabled or disabled with the ONLCR flag in the tcsetattr function, or with the `stty` program. On Windows, the console host does not convert LF to CR LF, so I assume this is instead done by some emulation layer in the Git for Windows package. If the emulated ONLCR flag has become turned off (e.g. because an editor such as `vi` turned it off and then was killed before it was able to turn the flag back on), that could cause the symptom described here. In this situation, `stty onlcr` or `stty sane` would turn the flag back on and make the output look OK again.

claunia commented

@j4james commented on GitHub (Sep 30, 2021):

FYI, on Windows this behaviour is controlled by the DISABLE_NEWLINE_AUTO_RETURN output mode. So maybe someone is setting that mode and not restoring it on exit. If that's the problem, it could potentially be fixed by #4954.

@j4james commented on GitHub (Sep 30, 2021): FYI, on Windows this behaviour is controlled by the `DISABLE_NEWLINE_AUTO_RETURN` output mode. So maybe someone is setting that mode and not restoring it on exit. If that's the problem, it could potentially be fixed by #4954.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Sep 30, 2021):

I was mislead by https://github.com/MicrosoftDocs/Console-Docs/issues/132.

Anyway, if I run stty -onlcr in Git Bash on Windows Terminal Preview 1.11.2421.0, and then run git --help | cat, it produces the ugly output. If I then start cmd in the same pane and run type to display a file that uses only LFs as line terminators, each line starts at the left margin. After that, if I exit from cmd to Git Bash and run git --help | cat again, the output is still ugly. This makes me believe the ONLCR flag is being emulated by MSYS (which is used by stty and cat but not by git) rather than mapped to DISABLE_NEWLINE_AUTO_RETURN.

@KalleOlaviNiemitalo commented on GitHub (Sep 30, 2021): I was mislead by <https://github.com/MicrosoftDocs/Console-Docs/issues/132>. Anyway, if I run `stty -onlcr` in Git Bash on Windows Terminal Preview 1.11.2421.0, and then run `git --help | cat`, it produces the ugly output. If I then start `cmd` in the same pane and run `type` to display a file that uses only LFs as line terminators, each line starts at the left margin. After that, if I `exit` from `cmd` to Git Bash and run `git --help | cat` again, the output is still ugly. This makes me believe the ONLCR flag is being emulated by MSYS (which is used by `stty` and `cat` but not by `git`) rather than mapped to `DISABLE_NEWLINE_AUTO_RETURN`.

claunia commented

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

So maybe someone is setting that mode and not restoring it on exit.

Correct; vim takes an output console from git with ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT adds DISABLE_NEWLINE_AUTO_RETURN | ENABLE_VIRTUAL_TERMINAL_PROCESSING and returns it dirty (even if it doesn't crash AFAIK).

adding functionality in Git for Windows that resets the terminal after vi returns workarounds the issue and will be present in a future release

@carenas commented on GitHub (Sep 30, 2021): > So maybe someone is setting that mode and not restoring it on exit. Correct; vim takes an output console from git with ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT adds DISABLE_NEWLINE_AUTO_RETURN | ENABLE_VIRTUAL_TERMINAL_PROCESSING and returns it dirty (even if it doesn't crash AFAIK). adding functionality in Git for Windows that resets the terminal after vi returns workarounds the issue and will be present in a future release

claunia commented

https://github.com/git-for-windows/git/releases/tag/v2.34.0-rc0.windows.1

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

FWIW the workaround from git to reset the terminal settings after vi is invoked has been merged and is released as part of the last Git for Windows prerelease:

This should avoid the most egregious cases until a final solution to keep them consistent is found

@carenas commented on GitHub (Oct 30, 2021): FWIW the workaround from git to reset the terminal settings after vi is invoked has been merged and is released as part of the last Git for Windows prerelease: https://github.com/git-for-windows/git/releases/tag/v2.34.0-rc0.windows.1 This should avoid the most egregious cases until a final solution to keep them consistent is found

claunia commented

@ghost commented on GitHub (Nov 18, 2021):

Can some help, gitbash terminal break in middle when i clear the old log then the new log start in the bottom.

@ghost commented on GitHub (Nov 18, 2021): ![image](https://user-images.githubusercontent.com/84894063/142355977-5e4f9a53-1d62-443e-b88d-918b152fea12.png) Can some help, gitbash terminal break in middle when i clear the old log then the new log start in the bottom.

claunia commented

@carenas commented on GitHub (Nov 25, 2021):

FYI, I made a fatal mistake on the way this workaround was implemented originally within git and therefore the code had to be reverted for 2.34.1, but luckily the Git for Windows maintainer picked it up and might still work when using 2.34.1.windows.1 (or later).

If you are having problems, make sure to NOT have any of the environment variables used to override the editor defined in your environment (ex: VISUAL, EDITOR, GIT_EDITOR, GIT_SEQUENCE_EDITOR) AND NOT have a core.editor setting, OR that they are set exactly to 'vi' or 'vim' ('vim.exe' or '/usr/bin/vi' will not activate the workaround and still corrupt your terminal).

@carenas commented on GitHub (Nov 25, 2021): FYI, I made a fatal mistake on the way this workaround was implemented originally within git and therefore the code had to be reverted for 2.34.1, but luckily the Git for Windows maintainer picked it up and might still work when using 2.34.1.windows.1 (or later). If you are having problems, make sure to NOT have any of the environment variables used to override the editor defined in your environment (ex: VISUAL, EDITOR, GIT_EDITOR, GIT_SEQUENCE_EDITOR) AND NOT have a core.editor setting, OR that they are set exactly to 'vi' or 'vim' ('vim.exe' or '/usr/bin/vi' will not activate the workaround and still corrupt your terminal).

claunia commented

@C0DK commented on GitHub (Feb 18, 2022):

I am experiencing something similar with WSL 2.0 and Ubuntu in the Windows Terminal, with git version 2.25.1 - yet that shouldn't be git for windows; but just plain old git:

It happens after having run an interactive rebase (which I assume is also when vim is opened.). I've set the editor to vim, (as per @carenas suggestion) rather than the full vim-path, yet it didn't do anything better or worse.

Is this related to the problem? and do you brilliant people know of any quick fix?

@C0DK commented on GitHub (Feb 18, 2022): I am experiencing something similar with WSL 2.0 and Ubuntu in the Windows Terminal, with git version 2.25.1 - yet that shouldn't be git for windows; but just plain old git: ![image](https://user-images.githubusercontent.com/9048078/154628132-006c41a6-44c6-43e6-b3b5-4bf413a76208.png) It happens after having run an interactive rebase (which I assume is also when vim is opened.). I've set the editor to vim, (as per @carenas suggestion) rather than the full vim-path, yet it didn't do anything better or worse. Is this related to the problem? and do you brilliant people know of any quick fix?

claunia commented

@carenas commented on GitHub (Feb 18, 2022):

Is this related to the problem? and do you brilliant people know of any quick fix?

the mentioned workaround only applies to git for windows (requires code in git that is not part of the regular codebase yet).

it definitely looks like the same problem, and as documented in #10152 another workaround that doesn't require code changes is to set TERM to something else than xterm*; ex:

> export TERM=vt100

it is important also to note that running reset after vi is invoked should also fix the terminal, as well as fixing your rbim command/alias so it doesn't attempt to run vi in a non terminal, if that is possible (expect might help there)

@carenas commented on GitHub (Feb 18, 2022): > Is this related to the problem? and do you brilliant people know of any quick fix? the mentioned workaround only applies to git for windows (requires code in git that is not part of the regular codebase yet). it definitely looks like the same problem, and as documented in #10152 another workaround that doesn't require code changes is to set TERM to something else than xterm*; ex: ``` > export TERM=vt100 ``` it is important also to note that running `reset` after vi is invoked should also fix the terminal, as well as fixing your rbim command/alias so it doesn't attempt to run vi in a non terminal, if that is possible (`expect` might help there)

claunia commented

@C0DK commented on GitHub (May 16, 2022):

I never tested vt100, @carenas - i did now.

vt100 didn't do much more than removing my beautiful colors. Reset is currently my preferred trick. but might just postfix the reset command to my alias.

@C0DK commented on GitHub (May 16, 2022): I never tested vt100, @carenas - i did now. ![image](https://user-images.githubusercontent.com/9048078/168536315-6d5d5dff-8e8d-40e5-9e25-1815bd14d257.png) vt100 didn't do much more than removing my beautiful colors. Reset is currently my preferred trick. but might just postfix the `reset` command to my alias.

claunia commented

@carenas commented on GitHub (May 16, 2022):

vt100 didn't do much more than removing my beautiful colors

will see if I can try again to get my fix merged into git upstream (hopefully for 2.37), which then could be maybe backported to your version; but considering your version is old and probably out of maintenance it might be worth upgrading it regardless.

@carenas commented on GitHub (May 16, 2022): > vt100 didn't do much more than removing my beautiful colors will see if I can try again to get my fix merged into git upstream (hopefully for 2.37), which then could be maybe backported to your version; but considering your version is old and probably out of maintenance it might be worth upgrading it regardless.

claunia commented

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

@carenas You know if this was ever fixed upstream? Or, if it wasn't, is there an upstream issue we could point this thread at?

@zadjii-msft commented on GitHub (Nov 8, 2022): @carenas You know if this was ever fixed upstream? Or, if it wasn't, is there an upstream issue we could point this thread at?

claunia commented

@carenas commented on GitHub (Nov 8, 2022):

You know if this was ever fixed upstream?

AFAIK the "fix" implemented in git for windows[1] is only a workaround to the effects of this bug.

[1] db157fb594

@carenas commented on GitHub (Nov 8, 2022): > You know if this was ever fixed upstream? AFAIK the "fix" implemented in git for windows[1] is only a workaround to the effects of this bug. [1] https://github.com/git-for-windows/git/commit/db157fb594b23192d438b0aa1002bf81388c643e

claunia commented

@othmanalikhan commented on GitHub (Feb 11, 2023):

I'm experiencing a similar situation where Git Bash for Windows messed up line wrapping (and consequently doesn't break lines properly). To replicate:

Open Git Bash session in Windows Terminal
Just press up-arrow to load a command from history
Move the cursor to the start of the line of the command that appears, and that becomes rather wonky (especially for long commands that should be line broken).

See this image to illustrate:

I should add that changing the $TERM variable can sometimes fix it but sometimes makes things even more wonkier.

EDIT: Nevermind, found my issue and it isn't caused by Windows Terminal... I had a function in my .bashrc that was overriding the $PS1 variable incorrectly. Fixed it and confirm everything is working. This issue was plaguing me for about a year now... But no longer.

@othmanalikhan commented on GitHub (Feb 11, 2023): I'm experiencing a similar situation where Git Bash for Windows messed up line wrapping (and consequently doesn't break lines properly). To replicate: 1. Open Git Bash session in Windows Terminal 2. Just press up-arrow to load a command from history 3. Move the cursor to the start of the line of the command that appears, and that becomes rather wonky (especially for long commands that should be line broken). See this image to illustrate: ![image](https://user-images.githubusercontent.com/5261295/218277992-cdc878d9-af8c-4f3a-8383-8ea490201840.png) I should add that changing the `$TERM` variable can sometimes fix it but sometimes makes things even more wonkier. EDIT: Nevermind, found my issue and it isn't caused by Windows Terminal... I had a function in my .bashrc that was overriding the $PS1 variable incorrectly. Fixed it and confirm everything is working. This issue was plaguing me for about a year now... But no longer.

claunia commented

@carlos-zamora commented on GitHub (Feb 22, 2023):

Hi all! There's been a lot of changes in this space recently, and we're hoping it gets better with 1.18 which is slated to come out in a few months.

@carlos-zamora commented on GitHub (Feb 22, 2023): Hi all! There's been a lot of changes in this space recently, and we're hoping it gets better with 1.18 which is slated to come out in a few months.

claunia commented