With larger than screen initial rows/columns, zsh prints extra "%" on startup.

[gwww]

What Operating System(s) are you seeing this problem on?

macOS

WezTerm version

wezterm 20220325-084058-4f2539f8

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Mysterious "%" showing up on start. Was not there on the last release (vs nightly) build.

To Reproduce

Just start wezterm.

Configuration

no config

Expected Behavior

No response

Logs

12:51:42.798 INFO wezterm_mux_server_impl::local > setting up /Users/glenn/.local/share/wezterm/gui-sock-63006
12:51:42.916 INFO wezterm_gui::termwindow > OpenGL initialized! Apple M1 Pro 4.1 Metal - 76.3 is_context_loss_possible=false wezterm version: 20220325-084058-4f2539f8
12:51:52.923 ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: EOF while reading leb128 encoded value

Anything else?

No response

[wez]

That looks like something zsh would output... are you sure you didn't change something in your zsh config/startup?

vercel/hyper#2144

[wez]

And: https://unix.stackexchange.com/questions/167582/why-zsh-ends-a-line-with-a-highlighted-percent-symbol/167600#167600

[gwww]

I ran the very latest and then the last release build. Only the latest has that. Will look...

[wez]

wezterm -n start -- zsh --no-rcs can be helpful to rule out zshrc issues

[gwww]

Thx for the command line to help rule out. Not there when I use that. Odd that it started with this new version. Looking at zsh start up now. Will report back.

[wez]

FWIW, the recording stuff "can't" impact anything like this. However, 638278f changes how we detect and set $LANG on macOS, so perhaps something in your zshrc is sensitive to that? Prior to this commit, we might not set $LANG in some circumstances, but after that commit, $LANG will always be set to some UTF8 locale.

[gwww]

In new version $LANG is en_CA.UTF-8.
In release build $LANG is also en_CA.UTF-8.

In starting release build about 10 times the % shows up there about 20% of the time. In latest build shows up 100% of the time.

When using wezterm -n start -- zsh --no-rcs to start the % does not show up.

When running with a empty .zshrc and no .zshenv the % shows up. Running zsh 5.8.1.

It appears to be something in the system startup. ¯\_(ツ)_/¯

I've ended up putting unsetopt PROMPT_SP in my .zshrc (from https://superuser.com/questions/645599/why-is-a-percent-sign-appearing-before-each-prompt-on-zsh-in-windows) which does the job.

Thanks for you help!!!!

[gwww]

I have narrowed this down to wezterm. Using wezterm start -- zsh --no-rcs to start and my wezterm.lua below, the problem happens. Note the commented out row/cols works (i.e.: no %).

local config = {}

-- config.initial_cols = 179
-- config.initial_rows = 47
config.initial_cols = 300
config.initial_rows = 100

return config

[wez]

Presumably the window is being resized smaller by the system while zsh is starting up. What does echo $COLUMNS x $LINES show in that scenario?

[gwww]

177 x 49 -- resizing indeed; and it must be outputting an empty string when doing so. It's when one of rows or cols is "huge" that this happens. When they are slightly larger than screen size it doesn't happen. Closing again, since I think you are right, zsh is doing something when the sizes are large.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.