Comment by bitbasher

1 day ago

This blog post reminds me of _why_ I use tmux. Did you see how much they needed to do to even resemble the workflow of tmux? Jeez, just use tmux. I don't mind dealing with wonky copy and paste once in a while.

> In summary: multiplexers add unnecessary overhead, suffer from a complexity cascade, because they actually have to translate escape codes, modifying them in hackish ways to get them to work with their concepts of windows/sessions.

What does that have to do with you using tmux? You're not the one maintaining tmux's codebase.

> I don't mind dealing with wonky copy and paste once in a while.

This problem is in no way unique to tmux. You have the same problem with any terminal app that takes over drawing, eg vim. That said it is also easy enough to fix.

The solution is OSC52, a terminal escape sequence that the emulator can use to interact with the system clipboard (kitty, alacritty, iterm2 all support this). The first step is to get you a script that writes out data in that protocol. Its easy enough:

    #!/usr/bin/env python3
    import os, base64, sys
    clip = base64.b64encode(sys.stdin.buffer.read())
    for pid in (os.getpid(), os.getppid()): # so that osc52-copy can be invoked by processes that themselves do not have a tty.
        cty = f"/proc/{pid}/fd/1"
        try:
            fd = os.open(cty, os.O_WRONLY)
            if os.isatty(fd):
                os.write(fd, b'\x1b]52;c;') # the actual escape sequence
                os.write(fd, clip)
                os.write(fd, b'\a')
                break
        except:
            continue
        finally:
            os.close(fd)
    else:
        raise SystemExit(f"no tty")

Now you can do this:

$ grep my_thing < some.txt | osc52-copy

And whatever got into osc52 is now on your system clipboard.

Tmux (set -g clipboard on) and nvim (unset clipboard) both have native osc52 support, and the script above can be used to integrate other places.

  • Terminal emulators have taken a very odd attitude toward OSC52. Many (or all?) of them selectively disable either copy, or paste, or both, depending on how cautious the maintainer is.

    Yes, it's true that an application that can read system clipboard content may scrape a password, but literally any application running in the terminal can read private keys out of your .ssh folder.

    With some heavy reading and a bit of experimentation, you can usually get this working, though.

    • But with OSC 52, any system I ssh into can scrape those passwords. Bigger attack surface, to be sure. And unfortunately there’s no particularly good way of telling if the received escape code originated from the local machine.

      1 reply →

    • There are lots of ways to secure your private keys though, including passphrases, having a ssh agent that requires interaction to use a key, having them on hardware security keys etc.

      Having osc52 paste default off seems very reasonable

  • I generally use xclip to copy program output. It has been around forever. Otherwise, I pipe into vim or I'm already using vim and I can copy via visual mode with "+y

  • What is the benefit of this over pbcopy and wl-copy?

FWIW I've submitted PRs to tmux and the maintainer Nick Marriott is very easy to work with. The codebase is well organized and things work pretty well. Reading the code made me like tmux even more.

I am tired of seeing people creating problems out of nowhere. The reasons author gave are stupid and I am gonna question his "7+ years" of tmux usage

  • I think some people should just admit they love tinkering with their tools instead of saying it is for productivity or whatever.

  • > and I am gonna question his "7+ years" of tmux usage

    Eh, lots of people use tools for ages without digging too deep.