Skip to content

'tmux;' passthrough: large sequences #487

Closed
Closed
'tmux;' passthrough: large sequences#487

Description

@cesarkawakami
cesarkawakami
opened on Jul 21, 2016

I'm currently working on a small script between tmux and iTerm2 for myself for clipboard integration.

I've worked out that it'd in theory be possible to combine tmux's tmux; passthrough and iTerm2's 1337;CopyToClipboard= escape sequence(1) to do a direct copy from the remote terminal to the local clipboard. I even have a script that somewhat works: https://gist.github.com/cesarkawakami/81a567af45a16522cb7ee20642feed41

The script emits something like this [newlines added for clarity]:

\033Ptmux;\033
\033\033]1337;CopyToClipboard=\007
<whatever>
\033\033]1337;EndCopy\007
\033\\

The problem I'm having is that the passthrough sequence has an upper bound on the number of characters that are passed through. If I'm emitting

\033Ptmux;\033<whatever>\033\\

and <whatever> is larger than (apparently) 211 characters, the command simply doesn't go through.

I've thought about chunking the input, doing something like:

\033Ptmux;\033
\033\033]1337;CopyToClipboard=\007
first_chunk
\033\\
\033Ptmux;\033
second_chunk
\033\033]1337;EndCopy\007
\033\\

But as soon as I emit the first \033\\, tmux emits some escape codes itself, adding spurious characters (from what I can see, they're always \033[1;1H) to the local clipboard.

Is there a way to either (1) avoid emitting these control characters temporariliy or (2) somehow work around the passthrough length limitation?

(1): https://www.iterm2.com/documentation-escape-codes.html

Activity

  1. nicm commented on Jul 21, 2016

    @nicm
    nicm
    on Jul 21, 2016 via email
    Member

  2. cesarkawakami commented on Jul 22, 2016

    @cesarkawakami
    cesarkawakami
    on Jul 22, 2016
    Author

    Oh wow, sorry about that. I've just realized I'm using a pretty old version, 1.8.5.

    I didn't even think this could be something that'd get better with more modern versions, limiting buffer sizes to the smallest possible value seems like the natural thing to do in general.

    Thanks for taking the time to comment that! I'll update my tmux version and rerun my tests.

  3. nicm
    closed this as completedon Jul 27, 2016

  4. wookayin commented on Oct 14, 2018

    @wookayin
    wookayin
    on Oct 14, 2018

    What is the length of passthrough buffer size? How can we escape a very long stream, if it's larger than the buffer size?

    UPDATE: From commit ada75af, it is 1048576 (1M) bytes. Input sequences longer than 1M will be discarded (as of current tmux).

  5. lock commented on Feb 15, 2020

    @lock
    lockbot
    on Feb 15, 2020

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

  6. lock
    locked and limited conversation to collaborators on Feb 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions