`wezterm imgcat` fails when invoked from a "non-Wez" Windows terminal

0x6675636b796f75676974687562 commented 3 months ago

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

20240623-130118-4daab4dc

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

Consider I'm launching a WezTerm instance on Windows, and connecting to a Linux box over SSH (or WSL). So I may be running ssh.exe from MSys2 to connect to a remote host, or wsl.exe (also from within WezTerm) in order to connect to a WSL instance.

Next, my Linux box also has WezTerm installed, so I can invoke wezterm imgcat on a remote host. In case this is a Windows-to-Linux connection, wezterm imgcat invocation fails:

^[[6;19;10t15:36:26.905  ERROR  env_bootstrap > panic at wezterm/src/main.rs:383:10 - attempt to divide by zero
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  15: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:360:3
  16: <unknown>

thread 'main' panicked at wezterm/src/main.rs:383:10:
attempt to divide by zero
stack backtrace:
   0:     0x55e05ab3eb5c - <unknown>
   1:     0x55e05ab71b60 - <unknown>
   2:     0x55e05ab39f7f - <unknown>
   3:     0x55e05ab3e944 - <unknown>
   4:     0x55e05ab40687 - <unknown>
   5:     0x55e05ab403ef - <unknown>
   6:     0x55e059d98713 - <unknown>
   7:     0x55e05ab40c98 - <unknown>
   8:     0x55e05ab409b9 - <unknown>
   9:     0x55e05ab3f026 - <unknown>
  10:     0x55e05ab40752 - <unknown>
  11:     0x55e059c396a5 - <unknown>
  12:     0x55e059c39743 - <unknown>
  13:     0x55e059cbcf96 - <unknown>
  14:     0x55e059cc284e - <unknown>
  15:     0x55e059cbde19 - <unknown>
  16:     0x55e059d6c763 - <unknown>
  17:     0x55e059d5bbb9 - <unknown>
  18:     0x55e05ab2f9a7 - <unknown>
  19:     0x55e059d5bbae - <unknown>
  20:     0x7f816e1ff24a - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  21:     0x7f816e1ff305 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  22:     0x55e059c39eee - <unknown>
  23:                0x0 - <unknown>

As you can see, in addition to the log message itself, the ^[[6;19;10t escape sequence is printed to stdout.

Is there any chance that cell_pixel_width and/or cell_pixel_height are zeroes?

PuTTY: interestingly, when I invoke wezterm imgcat from PuTTY, exactly the same problem occurs.
Alacritty (launched on Windows and connected to a Linux box over SSH): the same error.
Mintty (MSys2 or Cygwin): the image is correctly printed to the terminal, despite it's over a Windows-to-Linux connection. Given that Mintty supports both Sixel and iTerm2 image protocols, I assume wezterm imgcat internally uses one of those.
XTerm: no output, and no error either (the expected behaviour). The behaviour is the same, regardless of whether XTerm is launched on the local (Cygwin) or on the remote (Linux) host.

Versions:

Wezterm version on the client (Windows): 20240623-130118-4daab4dc (nightly).
Wezterm version on the server (Linux):
- 20240203-110809-5046fc22 (the latest release version available via Homebrew).
- 20240624-065522-552bb1d6 (the latest nightly version available via Homebrew).

To Reproduce

No response

Configuration

no config

Expected Behavior

No response

Logs

When just wezterm imgcat is run on the remote (SSH server) host, no new logs are produced under ~/.local/share/wezterm.

Anything else?

No response

wez commented 2 months ago

Duplicate of https://github.com/wez/wezterm/issues/4912#issuecomment-1925364809

github-actions[bot] commented 1 month ago

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.

wez / wezterm