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

"could not expand Ms" with terminal-overrides #3756

Closed
samogot opened this issue Nov 29, 2023 · 4 comments
Closed

"could not expand Ms" with terminal-overrides #3756

samogot opened this issue Nov 29, 2023 · 4 comments

Comments

@samogot
Copy link

samogot commented Nov 29, 2023

Issue description

I'm trying to enable clipboard forwarding through mosh according to:
https://gist.github.com/yudai/95b20e3da66df1b066531997f982b57b

set-option -ag terminal-overrides ",xterm-256color:Ms=\\E]52;c;%p2%s\\7"

when I add this option OSC 52 stops working at all (i.e. even through ssh instead of mosh).

i.e. the following command inside tmux doesn't set the clipboard:

> printf "\033]52;c;$(printf "%s" "clipboard" | base64)\a"

Server logs shows the following:

1701273750.514715 screen_write_start_pane: size 176x104, pane %0 (at 0,0)
1701273750.514727 input_parse_buffer: %0 ground, 20 bytes: \033]52;c;Y2xpcGJvYXJk\a
1701273750.514740 input_enter_osc
1701273750.514751 input_end_bel
1701273750.514761 input_exit_osc: "52;c;Y2xpcGJvYXJk" (end BEL)
1701273750.514769 input_osc_52: Y2xpcGJvYXJk
1701273750.514819 screen_write_start_pane: size 176x104, pane %0 (at 0,0)
1701273750.514844 could not expand Ms
1701273750.514852 screen_write_collect_flush: flushed 0 items (screen_write_stop)

Without the config it works.

I confirmed that the values are matched as expected:

# with config
> tmux info | grep Ms
 192: Ms: (string) \033]52;c;%p2%s\a
# without config
> tmux info | grep Ms
 192: Ms: (string) \033]52;%p1%s;%p2%s\a

#3646 Looks similar, but not the same. In my case default Ms expansion string works and i have newer version of ncurses. But it might be the problem with ncurses nevertheless.

I've seen reports that it is not working for a while, for example: mobile-shell/mosh#1054 (comment)

I know that there are workarounds to solve the XY problem and don't need terminal-overrides at all. For example with #3192 fixed, any tmux build from sources after ccc9dc3 would not require setting the override for my usecase to work. Unfortunately this doesn't seem to be included in latest release yet. Similarly building mosh patched with either mobile-shell/mosh#1054 or mobile-shell/mosh#1104 will help as well. Latter was what I was doing for several years, but custom builds is tedious to maintain, so after it broke again and I noticed mosh 1.4.0 is a thing, I am exploring again whether this is maybe solvable with stock builds.

Required information

> uname -sp && tmux -V && echo $TERM
Linux unknown
tmux 3.3a
xterm-256color
> dpkg-query -W | grep -E 'tmux|ncurses|tinfo|mosh'
libncurses-dev:amd64	6.4+20230625-2+build1
libncurses6:amd64	6.4+20230625-2+build1
libncursesw6:amd64	6.4+20230625-2+build1
libtinfo6:amd64	6.4+20230625-2+build1
libtinfo6:i386	6.4+20230625-2+build1
mosh	1.4.0-1+build2
ncurses-base	6.4+20230625-2+build1
ncurses-bin	6.4+20230625-2+build1
ncurses-term	6.4+20230625-2+build1
tmux	3.3a-4+build1
@samogot
Copy link
Author

samogot commented Dec 1, 2023

I compiled tmux from master and can confirm that it doesn't solve my problem.

Setting terminal-overrides still causes "could not expand Ms".

Without setting the terminal-overrides my actual use case still don't work. I assumed that printf is good enough simplified reproduction, but it is not. What I am using is tmux-plugins/tmux-yank plugin and it uses xsel. Unlike what I assumed, #3192 doesn't apply to OSC 52 sent from intercepting local clipboard, only to passing through existing sequences. In my case it still sends empty selection part regardless whether xsel --clipboard or --primary (etc) were used.
Example log (without terminal-overrides)

1701435179.851392 message: /dev/pts/1 key y: send-keys -X copy-pipe-and-cancel "xsel -i --clipboard"
1701435179.851401 cmd_find_from_client: s=$0 0
1701435179.851407 cmd_find_from_client: wl=1 1 w=@0 [tmux]
1701435179.851413 cmd_find_from_client: wp=%0
1701435179.851419 cmd_find_from_client: idx=none
1701435179.851428 cmd_find_target: target none, type pane, item 0x56433a1c4970, flags NONE
1701435179.851435 cmd_find_target: current is from queue
1701435179.851441 cmd_find_target: s=$0 0
1701435179.851448 cmd_find_target: wl=1 1 w=@0 [tmux]
1701435179.851453 cmd_find_target: wp=%0
1701435179.851459 cmd_find_target: idx=none
1701435179.851469 format_defaults: c=/dev/pts/1
1701435179.851475 format_defaults: s=$0
1701435179.851481 format_defaults: wl=1
1701435179.851487 format_defaults: wp=%0
1701435179.851504 format_expand1: expanding format: xsel -i --clipboard
1701435179.851511 format_expand1: result is: xsel -i --clipboard
1701435179.851522 utf8_to_data: 41000037 -> (1 1 7)
1701435179.851530 utf8_to_data: 41000037 -> (1 1 7)
1701435179.851537 utf8_to_data: 41000020 -> (1 1  )
1701435179.851543 utf8_to_data: 4100007e -> (1 1 ~)
1701435179.851550 utf8_to_data: 41000020 -> (1 1  )
1701435179.852146 job_run: cmd=xsel -i --clipboard, cwd=
1701435179.852306 job_run: cmd=xsel -i --clipboard, cwd=
1701435179.852736 run job 0x56433a22a300: xsel -i --clipboard, pid 1061032
1701435179.852783 screen_write_start_pane: size 177x104, pane %0 (at 0,0)
1701435179.852840 /dev/pts/1: \033]52;;IH4g\a
1701435179.852864 screen_write_collect_flush: flushed 0 items (screen_write_stop)

@nicm
Copy link
Member

nicm commented Dec 1, 2023

Your ncurses is probably too old.

@nicm nicm closed this as completed Dec 15, 2023
@samogot
Copy link
Author

samogot commented Dec 18, 2023

For posterity: I tried updating ncurses to version from debian-testing (6.4+20231121-1) but it didn't help. I end up using custom tmux with b7ea63b patch. After all, maintaining one custom tmux is easier then mosh-client and mosh-server on different machines.

Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants