Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Characters in the command line after entering tmux #4167

Closed
ziombo opened this issue Aug 19, 2023 · 8 comments
Closed

Characters in the command line after entering tmux #4167

ziombo opened this issue Aug 19, 2023 · 8 comments
Labels
bug Something isn't working waiting-on-op Waiting for more information from the original poster Windows Issue applies to Microsoft Windows

Comments

@ziombo
Copy link

ziombo commented Aug 19, 2023

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

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20230712-072601-f4abf8fd and 20230817-092749-87a00992 (nightly)

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

I'm using wezterm on windows and use it with WSL2 Ubuntu. I upgraded wezterm to the latest version and since then whenever I enter tmux (with 'tmux' command) I get some characters insterted by default:
image
61;6;7;22;23;24;28;32;42c

It's always the same characters and this doesn't happen when I run tmux within other terminals like Windows Terminal or standard command line.

To Reproduce

No response

Configuration

No changes in configuration, only updated wezterm to the latest version (also checked if something changes with nightly, but it doesn't)

Expected Behavior

No response

Logs

No response

Anything else?

No response

@ziombo ziombo added the bug Something isn't working label Aug 19, 2023
@wez wez added the Windows Issue applies to Microsoft Windows label Aug 20, 2023
@wez
Copy link
Owner

wez commented Aug 20, 2023

Please capture a terminal recording:

  • Launch wezterm. If possible, please use the default terminal size of 80x24 cells as it helps to keep things smaller and easier to manage.
  • Inside that terminal run wezterm record to start a recording session.
  • Run through your reproduction steps
  • Then type exit
  • You should see a message like:
*** Finished recording to /var/tmp/wezterm-recording-sF6B3u.cast.txt
  • Attach the file that it produced to this issue.

The file is an asciicast (compatible with https://asciinema.org/) and can also be replayed using wezterm replay.

The terminal recording allows me to replicate what is being sent to the terminal without requiring me to install the same applications as you and replicate your configuration for everything.

@wez wez added the waiting-on-op Waiting for more information from the original poster label Aug 20, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Sep 3, 2023

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

@github-actions github-actions bot closed this as completed Sep 3, 2023
@ferdinandyb
Copy link

wezterm-recording-dtHqGH.cast.txt

I can repro a very similar issue, wezterm consistently prints it's current version number (20230712-072601-f4abf8fd) into the terminal with possibly some other non-printable characters. Reattaching to a tmux session with vim open is not fun :)

@wez
Copy link
Owner

wez commented Sep 8, 2023

@ferdinandyb see #2060

@ferdinandyb
Copy link

Hmm, I tried "reasonable" numbers, but even set-option -g escape-time 10000 reproduces it.

@wez
Copy link
Owner

wez commented Sep 8, 2023

@ferdinandyb please open your own separate issue

@ferdinandyb
Copy link

Ok, I'll do that once I can install nightly (I just realized my local admin rights have been lost and this is the only windows machine I have access to).

@github-actions
Copy link
Contributor

github-actions bot commented Oct 9, 2023

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working waiting-on-op Waiting for more information from the original poster Windows Issue applies to Microsoft Windows
Projects
None yet
Development

No branches or pull requests

3 participants