Clipboard: Cut, copy, and paste anything, anywhere, all from the terminal | Hacker News Reader

Clipboard: Cut, copy, and paste anything, anywhere, all from the terminal

github.com

183 pointsthunderbong64 comments

Open articleView on HN

This looks neat, but as someone who doesn't use Linux on the desktop, I'm typically fine with

macOS (zsh/bash): command | pbcopy

windows (powershell) command | Set-Clipboard

I wrote a wrapper around these some years ago which I’ve been using since. It’s been working pretty well for me.

https://git.sr.ht/~charles/dotfiles/tree/171c95a20394552e02a...

The same flow for Linux can be had with 'xsel'

It sure can:

alias pbcopy='xsel --clipboard --input'

alias pbpaste='xsel --clipboard --output'

alias pbcopy='xclip -selection clipboard'

alias pbpaste='xclip -selection clipboard -o'

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

> if there's interest would be glad to refactor a bit and toss it on github

Even just upload it in its current state would be nice :)

here you go! https://github.com/nikvdp/pbproxy

yep, I want this and you're half way there!

what's the missing half? file transfer?

YOU put this together! I've just realised. What a dude! Great rally.

I'd like to do this with a client/server routine where the server will spit out to any client connected with a tunnel

Very interested

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.

There's Piknik: https://github.com/jedisct1/piknik

Looks exactly it!

This is interesting, I'd like something like that as well.

I'm doing some experimentation with something sort of along these lines via WebRTC.

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.

OSC 52 can do that, even for iPhone Blink terminal

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.

Defaults with vi keys:

  Leader+[: enter selection mode
  Space: start selection
  Return: copy selection
  Leader+]: paste

If you enable mouse in tmux, you just select to copy.

Then xsel -b / xclip -sel clip, or wl-clipboard for cli.

You could integrate it in vim as well but personally I like to keep that separate.

So why not just use OSC 52, which is built into most terminals? The functionality required already exists.

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)

[1]: https://github.com/ojroques/vim-oscyank

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.

The documentation is silent on how it interacts with the system clipboard. I would have expected the Compatibility section to address this.

Does it work on Cygwin (which has /dev/clipboard)?

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)

In that case please add that to the README. "copy anything anywhere" and "supports any up to date Linux" are blatant lies

Those are based on the goals of the project, not where it currently is (see the 0.1.3 version number)

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.

On windows there is already a built-in clip.exe (https://ss64.com/nt/clip.html) which was there like forever...

But it is nice to have this tool with more functionality on all platforms in unified way!

I discovered this just the other day and could not believe it had been there all along!

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.

> xclip (for Xorg)

There's also xsel as a long time utility for Xorg as well.

Where is the actual, platform-specific business logic in the source code of this software?

All I was able to find was https://github.com/Slackadays/Clipboard/blob/6fd7e6b695ebe57... , which opens the X11 connection -- but where does it actually read/write the selection (clipboard)?

It doesn't exist yet, the current code is just WIP.

> 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.

[1]: https://github.com/Slackadays/Clipboard/wiki/User-Experience...

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.

Origin of NO_COLOR [1] and relevant discussion on HN [2]

[1]: https://no-color.org/

[2]: https://news.ycombinator.com/item?id=30483417

Similar tool support Windows and OSX: https://github.com/b1tg/pickup

Not needed for MacOS, there is already pbcopy and pbpaste.

There are some differences: pbcopy copy data from stdin , `Clipboard` and `pickup` copy file to clipboard like right click copy.

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.

I use xsel for CLI stuff. You may want to check it out and add it to your toolbox

Thanks! I know about it and use it as well :) just not necessary when working in vim which covers most of my needs.

On OSX you can do something a little less fancy with pbcopy | pbpaste. I normally use it to copy text from files to an email / url output etc.

And I've used this for a few years, courtesy of https://news.ycombinator.com/item?id=10145362

I added the call to `ansifilter`:

function clip

if not tty >/dev/null

  ansifilter | pbcopy

 else

  pbpaste

 end

end

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.

> Is there a clipboard I can use without installing X or Wayland yet?

You're looking at it right now.

See other posts here about OSC 52

I'm still looking for a way to transfer text from a remote server in VS Code to the local system. Anyone have that?

In Linux this is trivial.

There's a number of clipboard management and inspection tools such as xclip and you can bind keys to do arbitrary commands with a bunch of tools.

There's a wide variety of ways to send stuff over the network as well.

The architecture is pretty obvious

Copy on remote, clipboard manager emits over network, local server picks up text, puts in clipboard.

This is like a few hours at most

Can't test, I don't see any mention of X or Wayland, is it safe to assume it works on both?

a similar tool is https://github.com/brunelli/wl-clipboard-x11 and xclip (for Xorg).

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.

You're being pointlessly pedantic.

It's pretty clear what "terminal" means in this context. Nobody uses the term in the classical mainframe sense, so "emulator" is implied.

And you brought up "multiplexer". It's neat that you use it for clipboard management, but this tool does much more than that.

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.

Userspace replacement for Linux kernel-provided virtual consoles/terminals

https://cgit.freedesktop.org/~dvdhrm/kmscon/plain/README

> echo "yo mama" | cb

> cb > really_large_objects.txt

Did not expect that.

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.

Reply on news.ycombinator.com