After using moar my terminal is corrupted

[colinmollenhour]

I'm using bash with Starship 1.13.1 and a few common plugins, nothing crazy (here).

After I quit moar the terminal position is messed up and I can't see what I'm typing.. If it type "reset" the terminal will reset successfully but this is obviously no good to do all the time. I have not experienced this issue with any other pagers or any other terminal apps.

[walles]

I'll try to repro, but first some questions:

1. Can you try with moar --trace somefile.txt and post the output?
2. What terminal are you using?
3. What shell are you using?
   • (bash, I just read more carefully)
4. Has this been broken for long, did it break recently or don't know?

[walles]

Could you try with the latest version of starship? 1.13.1 is over a year old.

I failed to repro, here's my setup:

• macOS
• moar v1.24.3
• iTerm2
• starship 1.19.0
• bash v3.2
• Your starship.toml file.

Any ideas what could be different on your end?

If you could do PAGER=moar MOAR='--trace' git diff that would be super!

[aNNiMON]

I think I faced almost the same issue, but I'm not sure if the problem exactly in moar. When using moar as a regular command, it works well. However, when spawning moar process from yazi, the input is blocked after exiting.

https://github.com/walles/moar/assets/1321838/d3f7e853-bce5-4d4c-b4a8-53a97b91ff4b

Steps to reproduce:

1. Start yazi
2. Press : and type moar file.txt
3. Exit moar Result: now some key input (arrow keys, Enter, etc) don't work in yazi

However, after spawning an editor, it works well:

1. Start yazi
2. Press : and type moar file.txt
3. In moar press v to open an editor
4. Exit editor Result: everything works as usual

Version: v1.24.5
LANG   : en_US.UTF-8
TERM   : xterm-256color
MOAR   : --trace
EDITOR : winpty nvim

GOOS    : windows
GOARCH  : amd64
Compiler: gc
NumCPU  : 16

time="Jun 29 13:04:47.409602" level=debug msg="Counted 52 lines in 0s at 0s/line"
time="Jun 29 13:04:47.410111" level=debug msg="Stream read in 0s"
time="Jun 29 13:04:47.470609" level=debug msg="Terminal background color still not detected after 60.1902ms, giving up"
time="Jun 29 13:04:47.470609" level=debug msg="Using style <native>"
time="Jun 29 13:04:47.470609" level=trace msg="Pager starting"
time="Jun 29 13:04:47.476302" level=trace msg="Reader done, contents explicitly set"
time="Jun 29 13:04:47.476302" level=debug msg="onDone() took 66.1906ms"
time="Jun 29 13:04:49.364808" level=trace msg="ttyin high watermark bumped to 3 bytes"
time="Jun 29 13:04:49.364808" level=trace msg="Handling key event 5..."
time="Jun 29 13:04:49.541164" level=trace msg="Handling key event 5..."
time="Jun 29 13:04:50.019415" level=trace msg="Handling rune event 'q'/0x0071..."
time="Jun 29 13:04:50.019415" level=trace msg="Pager done"
time="Jun 29 13:04:50.677345" level=debug msg="ttyin read error, twin giving
up: read /dev/tty: file already closed"
time="Jun 29 13:04:50.677345" level=debug msg="Problem restoring TTY state: The handle is invalid."

I'll also try in other operating systems later

[walles]

Thanks @aNNiMON!

The --trace output that you posted, is that from the run with problems or the run without?

I'll also try in other operating systems later

That would be super!

Since I can't repro this (I tried following your instructions) it might be Windows specific, and that would be good to have confirmed.

[walles]

Can you try this binary @aNNiMON?

moar-v1.24.5-1-gb2b6985-windows-amd64.exe.gz

I don't have a Windows setup, but I think b2b6985 might improve things.

It will restore stdout even if restoring stdin fails.

And I believe restoring stdin did fail, based on your --trace output (thanks!).

[aNNiMON]

@walles my issue is not reproducible neither with linux-arm binary (termux Android), nor with linux-amd64 (Debian 12).

On Windows I tried your 1.24.5-1 build, but still same result. Here's updated trace:

Version: v1.24.5-1-gb2b6985
LANG   : en_US.UTF-8
TERM   : xterm-256color
MOAR   : --trace
EDITOR : winpty nvim

GOOS    : windows
GOARCH  : amd64
Compiler: gc
NumCPU  : 16

time="Jun 29 16:41:39.645419" level=debug msg="Counted 25 lines in 0s at 0s/line"
time="Jun 29 16:41:39.645955" level=debug msg="Stream read in 0s"
time="Jun 29 16:41:39.703969" level=debug msg="Terminal background color still not detected after 57.4855ms, giving up"
time="Jun 29 16:41:39.703969" level=debug msg="Using style <native>"
time="Jun 29 16:41:39.703969" level=trace msg="Pager starting"
time="Jun 29 16:41:39.709538" level=trace msg="Reader done, contents explicitly set"
time="Jun 29 16:41:39.709538" level=debug msg="onDone() took 63.5837ms"
time="Jun 29 16:41:40.827082" level=trace msg="ttyin high watermark bumped to 1 bytes"
time="Jun 29 16:41:40.838167" level=trace msg="Handling rune event 'q'/0x0071..."
time="Jun 29 16:41:40.838167" level=trace msg="Pager done"
time="Jun 29 16:41:41.581806" level=debug msg="ttyin read error, twin giving up: read /dev/tty: file already closed"
time="Jun 29 16:41:41.581806" level=debug msg="Twin screen main loop done"
time="Jun 29 16:41:41.582399" level=debug msg="Problem restoring TTY state: failed to restore terminal state: [failed to restore stdin console mode: The handle is invalid.]"

The --trace output that you posted, is that from the run with problems or the run without

Turns out this trace is same no matter if I spawn process from yazi, or just from terminal.

[aNNiMON]

I think I know what's the reason. Git Bash uses mintty, thus most commands require running through winpty. Problem can be solved by running winpty moar <file> or by adding an alias for moar.

https://github.com/walles/moar/assets/1321838/88217130-ae98-402a-ae16-c23944cc1f84

[aNNiMON]

In cmd and powershell both versions v1.24.5 and v1.24.5-1-gb2b6985 keep breaking a terminal input. In cmd it's broken until clear is typed. In powershell when trying to type something after exiting moar, the powershell process hangs and closes.

https://github.com/walles/moar/assets/1321838/fad88af4-0ee0-4303-8604-1feb89e79e08

Trace from powershell:

Version: v1.24.5-1-gb2b6985
LANG   :
TERM   :
MOAR   :
EDITOR :

GOOS    : windows
GOARCH  : amd64
Compiler: gc
NumCPU  : 16

time="Jun 29 17:56:31.395272" level=debug msg="Counted 19 lines in 0s at 0s/line"
time="Jun 29 17:56:31.395806" level=debug msg="Stream read in 0s"
time="Jun 29 17:56:31.395806" level=debug msg="onDone() took 0s"
time="Jun 29 17:56:31.461615" level=debug msg="Terminal background color still not detected after 64.7565ms, giving up"
time="Jun 29 17:56:31.461723" level=debug msg="Using style <native>"
time="Jun 29 17:56:31.461723" level=trace msg="Pager starting"
time="Jun 29 17:56:32.066249" level=trace msg="ttyin high watermark bumped to 1 bytes"
time="Jun 29 17:56:32.066249" level=trace msg="Handling rune event 'q'/0x0071..."
time="Jun 29 17:56:32.066249" level=trace msg="Pager done"
time="Jun 29 17:56:32.431383" level=debug msg="ttyin read error, twin giving up: read /dev/tty: file already closed"
time="Jun 29 17:56:32.431383" level=debug msg="Twin screen main loop done"
time="Jun 29 17:56:32.431922" level=debug msg="Problem restoring TTY state: failed to restore terminal state: [failed to restore stdin console mode: The handle is invalid.]"

[colinmollenhour]

1. Can you try with moar --trace somefile.txt and post the output?
2. What terminal are you using?
3. What shell are you using?

I'm using Windows Terminal (I think it was installed from Microsoft Store) and the built-in terminal for IntelliJ PhpStorm. Ubuntu on WSL2, not Git Bash. Now I can't reproduce it..

4. Has this been broken for long, did it break recently or don't know?

I'm a new user so this was my first time using moar.

[walles]

@aNNiMON can you try with this (older) release on Windows? Does it have the same problems as the latest release?

https://github.com/walles/moar/releases/tag/v1.23.15

[aNNiMON]

@walles 1.23.15 works well

221 also works well on this version

[walles]

This Windows specific issue should be fixed in just-out v1.24.6.

[aNNiMON]

@walles works fine, thank you

[walles]

If you can, any help looking into #222 would be highly appreciated!