I wish there was a tool that allowed me to send my clipboard to a server and anytime I sent something to the clipboard it checks the ssh hosts file for the config and sends it off. I'd like to 'paste' on any other machine with an ssh command.
I keep a cobbled together version of something like this in my rc files. The ui mimics macOS’s pbcopy/pbpaste commands (it degrades gracefully on linux boxes too by falling back to xsel if available, and then to a tmp file for use on headless servers).
The special sauce is that you can put a server name from your ssh config on the end of a pbcopy or pbpaste command so you can do stuff like run `echo hello | pbcopy server2` on server1, after which doing `pbpaste` from server2 would print 'hello'. You can also do this in the other direction with pbpaste, eg from server2 you can run `pbpaste server1` and it'll print out the contents of server1's clipboard.
The current setup is a bit coupled to my rc files, but if there's interest would be glad to refactor a bit and toss it on github
I use https://github.com/BlakeWilliams/remote-development-manager for this, which works by running a server and forwarding its socket over the SSH connection. If you’re willing to add some aliases and editor/ssh config you can easily get a UX that feels like a unified clipboard across remote hosts. My favorite use is integrating the yank buffer of remote vim processes with my local system clipboard.
Though not exactly the same, I did create a project for easy sharing of clipboard https://github.com/krishnaraj/oneclipboard. Lost interest after background Clipboard access was restricted in Android 10 or something.
tmux (on workstation) integrates naturally with system clipboard and after finally getting it into my workflow, none of the annoyances in the readme anymore. It Just Works.
Yes OSC 52 is very handy for vim over SSH: instead of X11 forwarding - you can just yank text from remote vim into the local clipboard using OSC 52 [1].
Overall it's much quicker - as yanking in vim with X11 forwarding and '+clipboard' sometimes had a delay.
(ps: I think OSC 52 is implemented in xterm and URXVT, but not yet in gnome-terminal)
libvte, which several exceedingly basic terminals use (including gnome-terminal) is basically no longer maintained, and is on life support provided by its few consumers. It will probably never get OSC 52 support (and support of many extensions), unless it truly scratches someone's itch, and they can hound maintainers into accepting a patch.
That said, there are many great modern terminals to use. I suggest Alacritty.
From a quick scan of the source, it should support Wayland. But the binary from the releases doesn't seem to. I presume it was compiled with only Xorg support.
Clipboard doesn't have support for either Xorg or Wayland yet, but the headers are already included to make it easier to add when it's ready. I know this because I wrote Clipboard (check my submissions)
Then the readme should say that, because it currently presents itself as being a complete and functional solution. In fact, the readme only mentions Windows support as being WIP, which implies that everything else isn't. And the version number doesn't tell us anything about functional completeness; people frequently use 0.x only to mean that they're not committing to any stability guarantees.
I’m curious how this is implemented to work with all the different window systems without dependencies.
edit: OK I looked at the source code, it does actually include the windowing system headers and use the base libraries.
I'm glad there are people not afraid to use the latest version of programming language features. I always try to use C++20 for new projects, but often the dependencies prevent me.
If you want to use the clipboard from cmdline you can also use
xclip (for Xorg)
wl-clipboard (for wayland)
and on macOS you can use the builtin commands: pbpaste pbcopy (see the man page)
These are what I’ve been using, but I might change now.
> Clipboard works on any up-to-date Windows, Linux, Android, macOS, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, or OpenIndiana system, or anything that supports C++20, all with ZERO dependencies. Yes, really!
It doesn't have any dependencies, as it checks for X11 or Wayland library availability upon compilation and gets rid of any X11/Wayland code if those libraries aren't found.
From the Clipboard "User Experience Manifesto" [1]:
Clipboard does not have any configuration. Note that I said "have," not
"use." That's because Clipboard cleverly picks up on certain settings that
are present everywhere they're possibly used. One such setting is
NO_COLOR. NO_COLOR is an unofficial standard to specify a global disabling
of color output by software. If the NO_COLOR environment variable is
defined, then programs should not display color.
I'm unaware of many programs that actually respect $NO_COLOR. Certainly `ls` and `grep`, the two programs I use the most which display colored output, don't respect that environment variable. `ag` doesn't respect it either. In fact, the only program I use on a semi-regular basis which respects $NO_COLOR is `fd`. All the rest expect a `--no-color` command line parameter to disable colorized output. Given that, I'm wondering why the authors chose to control output colorization with an environment variable, rather than a command line argument.
Neither ls nor grep output color by default. Most distributions have a bashrc script that sets aliases like:
alias grep='grep --color=auto'
alias ls='ls --color=auto'
Ls and grep are defined such that you can specify --color multiple times and the last one will take effect, allowing you to disable coloring while still using the alias that enables it. The FAQ at no-color.org states:
> User-level configuration files and per-instance command-line arguments should override $NO_COLOR
So, it looks like like ls and grep respect it fine with just their default behaviour.
As an aside, at least on my system, ls and grep do not recognize --no-color. I need to specify it with --color=never.
On Debian derivatives, vim-gtk is built with X clipboard support via the “ register. +”yy will yank the current line to the X clipboard and so on. Note vim-gtk does not force you to use the gtk version; the terminal version it includes (which replaces the usual one via alternatives) also has “ support.
Interesting. Currently I use https://hluk.github.io/CopyQ/
but I would be happy to optimize my workflow and look for a good integration in sway/wayland and possibly dmenu.
xsel kind of works but I would like to copy paste anything
Is there a clipboard I can use without installing X or Wayland yet?
Tmux and GNU screen have their own copy buffers but they're not so useful when you're copying text from separate vim instances, scrolling both up and down in vim.
What is the difference between "the terminal" and the "terminal emulator".
This appears to be for the terminal emulator. I gave up on X11 and its successors many years ago in favor of what was called, at the time, "VGA textmode". No framebuffer, unfortunately. Have not used a mouse outside of work in thirty years. "Clips" for me are captured (copied) from pipes or from pseudo-terminals, saved in buffers and pasted into pipes and pseudo-terminals.
A "terminal multiplexer", i.e., tmux, is the solution I use as a "clipboard", namely what tmux calls "saved buffers". Specifically the commands I use are load-buffer, save-buffer, paste-buffer, list-buffers and delete-buffer.
So what the heck is "the terminal". The way HN commenters use the term it probably means "the terminal emulator". But perhaps it is an umbrella term for textmode, multiplexer and emulator.
Your text mode console is also a terminal emulator, albeit one provided by the kernel.
Very few people use hardware terminals; the scarcity has driven prices up to the point where it is sometimes cheaper to get a full computer, monitor, keyboard and serial adapter than to buy a working VT-series terminal.
Clipboard is one of few prime candidates for a “flip the table and start over from scratch”
-style revolution. Almost everything about it sucks: it’s largely vendor/platform/distro/window-manager (heck even text-editor) specific. It has a huge amount of accumulated complexity, it has security issues, and yet it’s not flexible enough for power use cases like multiple clipboards.. and non-technical users struggle a lot with simple cases.
It’s so frequently used it deserves prime physical real estate of one or two dedicated keys. It deserves a standardized API for at least image data, text, files, and an extension system, that works the same across platforms. Most importantly it needs discoverable, inspectable consistent UX that can be taught in schools and to seniors.
I’m not saying it’s easy, clipboard is almost by definition shared mutable state, which is hard and messy. Then it needs to work with touch screens, cli and maybe even other interfaces. And its closely related cousins, like drag and drop and selections, are also important and related UX considerations.
Disclaimer: I’m a little bit intentionally provocative, and I should probably really be more careful what I wish for, since any major change inevitably runs into (major) problems (see exhibit A – ipv6). I am partly just venting - after all these decades we certainly have enough experience to build something better. We certainly deserve it.
Yes - bang for the buck, you probably couldn't do much better than improving some part of cut/copy/paste/drag/drop. I think what's needed is an inverted Infinate Canvas approach with ring fenced buckets for each copy/cut event. I sort of use that now keeping a web service page open on multiple machines to push/pull through.
macOS (zsh/bash): command | pbcopy
windows (powershell) command | Set-Clipboard