Show HN: Clyp – Clipboard Manager for Linux | Hacker News Reader

Show HN: Clyp – Clipboard Manager for Linux

github.com

79 pointstimeoperator48 comments

One thing that I love about Windows (and there aren't many others) is that pressing Super+V (instead of Ctrl+V) shows a list of last N clipboard entries and you can select which one you wish to paste. Simple and very effective.

You can also pin some entries so that they are permanently available, but that's a bonus.

I haven't seen a clipboard manager behave like that in Linux - can this one be used in a similar way?

I use a popup like that myself a lot. Clipman on xfce supports that but no pinning.

The "Clipboard History"[0] Gnome extension also does this quite well in my experience. I also recently switched from Windows 11 (to Ubuntu), very happy so far.

Edit: Supports pinning and binding it to Super+V as well!

[0] https://extensions.gnome.org/extension/4839/clipboard-histor...

Yes, I this is the feature I miss most; I'm almost ready to try to remember how to write in C.

Tried it, and found out I had disabled it in the past, and it fortunately has stayed off trhough updates.

How does it deal with usernames/passwords/secrets in the clipboard? Do you clean it up periodically?

I looked at mine, and it only has entries from my current login session.

That, and it only has about 10 of them. But anyway, if someone can access your clipboard manager then that's not very good...

If someone has access to your computer to access your clipboard history, you're already been pwned and the clipboard with random scattered entries is the least of your worries.

Use a password manager/passkey so you don't have to do this

Sometimes you have broken websites/apps so you gotta copypaste. Sometimes they even have fields where you can't paste either (K9mail on android) (I cry in 64 char password).

It'd be an interesting feature for a password manager to issue a system call to purge clipboard history on copying a password. Lots of password managers aren't just browser add-ons but full desktop apps

I configured copyq to work exactly like this, so it's doable.

Yup as others have said, super+v for me invokes greenclip's rofi plugin which gives me a nice themable clipboard history overlay.

I’ve used ditto for this since before windows gained this capability. It also has an ignore list (e.g. keepass lives there) and a few other niceties which make it one of the first tools I install on a windows box (not very often anymore, granted).

Ditto is unparalleled. Ugly, but unparalleled. I've been using it for ages and every time I use a system without it I feel it's absence.

KDE's default clipboard manager lets you summon a list (and you can change what shortcut to invoke it and do things like use a shortcut to move to the next clipboard entry) and edit entries. It doesn't let you pin them though, I think.

I love that feature too. I replicated it with this. https://github.com/sentriz/cliphist

In addition to what is shown here, I added a job that runs every 5 minutes which prunes the history so that I can comfortably copy sensitive information as well.

https://github.com/SUPERCILEX/gnome-clipboard-history

Can show last N entries and has a search bar as well, so you can click type away and cycle through results with TAB. Supports pinning as well.

I'm using Gnome. On Gnome, you could just install "Clipboard Indicator" or something like this in Gnome Extension and set shortcut as "Super+V". It's pretty easy, I think.

> I haven't seen a clipboard manager behave like that in Linux

Selection bias aside, Linux clipboards with history have existed for close to two decades, possibly more.

I thought wayland had some restrictions on global clipboard access and the last time I tried none of the well known clipboard managers worked as expected. (Also they all looked like shit).

This has been one of my pain points switching from macOS to linux or windows. Great job.

I actually went looking at the source code to see if this would work on Wayland and it doesn't. The clipboard snooping is implemented by listening for events using gdk.Clipboard, which is not an ext_data_control_v1 implementation. So on Wayland it'll only notice clipboard events if it's in focus (or if the compositor sends clipboard events to unfocused windows, which I'm not sure any do).

https://github.com/murat-cileli/clyp/blob/2c0ce6c33813c3f35f...

Edit: Yes, tested it now and it doesn't detect clipboard events from Wayland windows when it doesn't have focus. It only detects events from Xwayland windows when unfocused, or if I copy something from a Wayland window and then focus the clyp window then it detects the thing I copied.

It's almost as if a Wayland compositor should keep a list of trusted apps to broadcast clipboard events to, somehow similar to how screenshots are handled. (Not that Wayland is well-rounded in this regard.)

The ext_data_control_v1 protocol I mentioned is a protocol specifically for clipboard managers. So a client that wants to be a clipboard manager would implement that protocol. There are already implementations of it like wl-clipboard. There is no need for the compositor to broadcast regular clipboard events (wl_data_offer).

Now the compositor could certainly keep an additional list of trusted applications that are allowed to be clients of the ext_data_control_v1 protocol. Though identifying the client to enforce such a thing is a bigger problem than just maintaining a list of applications, because the protocol has no client identification. AFAIK every compositor that supports that protocol has no restrictions on clients requesting it, though something involving the security-context protocol might change this in the future.

Hyprland has sort of permission handling https://wiki.hypr.land/Configuring/Permissions/ But yeah there isn't really a "standard wayland ecosystem way"

I see the prompt-less permission config is based on the executable path. How does it get the executable path for the client? And is it robust against me spinning up a mount namespace with an arbitrary /usr/bin/grim that I control?

Probably not

Odd, why does the readme tout "Full Wayland support" then?

Because its easy to write it and most wont even verify?

That's interesting.. Never ran into this, been using various clipboard managers in wayland (swaywm at first, now niri) for years without issue. copyq is what I use these days and, while not quite as pretty as this one, its great!

I use CopyQ. Love it because it's so cross-platform, and consistently works across my Mac and Linux machines with minimal fuss; it handles images really well too.

And you can sync your clipboard history across devices! Super handy feature

Great work! does the CLI support clipboard operations like MacOS' `pbcopy` and `pbpaste` ? I've added it to my stars to keep and eye on the project, GTK4 and wayland support makes it rather futureproof IMO

For Wayland I just use this:

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

I used to do the same thing on Xorg with xclip I think

Switching between macOS for job and linux for everything else, I’ve honestly never realized any difference.

I'm confused; xsel, as you might imagine from the name, is very specifically a program for manipulating the X11 selection and clipboard. So it does work on Xorg, but I'm very confused that it would work in any meaningful capacity on Wayland. Are you somehow using Xwayland?

I run KDE usually so I imagine it's xwayland.

It would be nice if you could pipe to it like pbcopy, with each invocation creating a new entry, and add support for automatically expiring old entries.

There's wl-clipboard for this, has wl-copy and wl-paste commands. I've been using it on sway for years.

Linux clipboards have been a pain point to me for decades. What I really want is a single unified clipboard daemon that works across different login sessions and covers console and graphical environments with the same keyboard shortcut. Bonus points if it's got a single-use-paste option for passwords, and also buffers to hold onto multiple selections.

For clarity, are you expecting a clipboard in full terminal sessions (including serial?) or are you just meaning pty sessions with a terminal emulator?

I'm not sure how a clipboard manager would know the text copied in was a password (or 2fa).

> a single-use-paste option for passwords

This wouldn't prevent the malware that's constantly scanning the clipboard from stealing your password; it would only prevent you from using it after it's been stolen.

I would think that would at least have the advantage of making it easier to detect the problem?

Congrats on the release, I went the other way around, osx first in my case https://github.com/fkhadra/xcp, I'll probably add support for linux and windows when I get the time. Funny that we both used golang for that.

On Debian, I use a zeitgeist-compatible clipboard, and a rofi menu to fuzzy search / select the entries. Zeitgeist uses SQLite as well. It has only ever given me grief when I copied a very large image (>50MB) to the clipboard.

Why images are limited to 3 and are there plans to fix that?

Does it support indicators? If not, any plans to add it?

These clipboards are a privacy problem when you're sharing your screen. So many times a coworker has copy/pasted and a dialog with even passwords have been shown on screen...

Great point. It should be excluded from sharing session.

Reply on news.ycombinator.com