Menu to delete clipboard entries

Hi there,

just tried out your tool. Great work :+1:

Would it be possible to remove (also via rofi/dmenu) specific entries manually. This is because of the following reasons.

1. I use a password manager from where i regularly copy passwords in order to paste them somewhere. Now when using clipmenu and someone else is sitting next to me, he/she will see my passwords. I'd really like to clear that out before. Some examples could be:
   • Clear all entries
   • Clear currently selected entry (current selectoin with rofi/dmenu and some key-combo to clear)
2. Second thought I had is that I don't want my passwords to be permanently stored somewhere. So I want to make sure they will be removed.

Yeah, this is reasonable (although storage shouldn't be permanent assuming /tmp is tmpfs, but tmpfs can swap).

The better way would be to just not record them at all. If I added a way to temporarily disable clipmenud's monitoring for N seconds without stopping the daemon, would that work for you?

Disabling it for X sec is another good thing. But I think to selectively delete something from the list is a killer feature.

---

FYI: As far as I know, when using keepassx, the copied content will be auto-removed from the clipboard (when not using a clipboard manager). I have no idea how it does this, but that would be another good feature:

It does this by copying the empty string to the clipboard, or storing the value prior to copy and then restoring it (again, through copying). In this case there's nothing to delete since the X buffer only holds one entry.

As for auto-clear, we should discuss that in another issue, but I'm not sure what the use case is without an example.

As deletion would require an additional action, it should be introduced with an explicitly set startup option for the client to not break compatibility with current setup.

You could have a double choice then:

1. choose clipboard entry
2. choose action to perform (copy or delete)

Some basic shell stuff to show you what I mean:

choice="$( printf "asd\ntest2\ntest3\n" | dmenu)"; action="$(printf "copy\ndel\n" | dmenu)";

Here are some ideas for clipdel:

• Clear last entry
• Clear entries in last N minutes
• Clear high entropy entries (with ent?)
• Clear all entries

Now that we have flocking, this should be easy enough

The list looks good. Can you explain what high entropy entries are.

ie. "things that look like passwords", which appear random/high entropy

A clipdelmenu which allows you to select items to delete in dmenu would be cool.

ie. "things that look like passwords", which appear random/high entropy

I wouldn't go with this. It is more or less impossible to judge if something is a password or not.

For what it's worth, it's not really impossible to detect token-like passwords -- this is something I have actually worked on professionally :-) But yes, it's something that's only a nice to have alongside the others.

clipdel is now in the repository, which permits removal and listing based on regexes: 72760da7a46ac570c220eb333dad40be1b5f68b7

clipdelmenu will be next, which just allows selecting a specific clip and will be a wrapper around clipdel.

At some point, clearing high entropy entries with clipdel ent would be great.

5.3.0 just went out with clipdel. :-) I'll leave this open for clipdelmenu's arrival.

Would it be possible to remove (also via rofi/dmenu) specific entries manually.

Why complicate?

X maintains three selections ("clipboards"), called PRIMARY, SECONDARY and CLIPBOARD.

clipmenud disregards SECONDARY. Thus all you need to do is use that one for passwords and circumvent clipmenu altogether.

If you use pass as password manager, that comes down to running pass show github.com | head -n1 | xsel --secondary and then having some hotkey defined that pastes and clears that selection like so:

xdotool type `xsel --secondary` && xsel --clear --secondary

Now what really makes this a sexy approach, is that you can have your password and your username clipped at the same time - username in PRIMARY, password in SECONDARY.

---

Roughly 2 years ago I realized that this project was heading in a direction of unnecessary complexity (no offense). Thus I decided to stay on my own fork, focusing on simplicity and performance.

Love clipnotify though;

For what it's worth, it's not really impossible to detect token-like passwords -- this is something I have actually worked on professionally :-)

Even within context, there's no bulletproof way of knowing if something like "call me maybe" is a password or some text you copied.

Deleting from the clipboard history does make sense, but I'll just go about it with a quick rm -f /tmp/clipmenu.$USER/* :)

(deleted spam.)

So, I was thinking of the best way to implement a clipdelmenu and came to the conclusion that we don't need it. 99% of the needed code — the 1% part being change the action after selection — is already there in clipmenu, so there's no reason to duplicate it.

And then I have two proposals, and I'd like some input on which would be the best implementation (or if it'd make sense to implement both):

1. When clipmenu is piped it prints to stdout instead of calling xsel (I think it makes sense to be implemented regardless of this feature) on the selection, so we can do something like clipmenu | clipdel -d --exact-match (after some changes in clipdel).

2. Create a soft link clipdelmenu pointing to clipmenu, and if $0 equals to clipdelmenu (i.e. clipmenu runs by executing the clipdelmenu soft link) it calls clipdel -d on the selection, instead of xsel.

Both should be easy to implement and most of the work would be done in clipdel to support reading from stdin (#91), exact match deletion and things described in https://github.com/cdown/clipmenu/issues/57#issuecomment-366728601.

I guess just a simple clipmenu -d wouldn't be good because it should still pass all arguments to dmenu?

Both options seem a little hacky to me. Maybe we could move the entire selection stuff into a separate file and have both clipmenu and clipdelmenu just call that one to get a selection?

I guess just a simple clipmenu -d wouldn't be good because it should still pass all arguments to dmenu?

No, no. The current code works like clipmenu [ARGS] | clipdel.

Both options seem a little hacky to me.

I've just pushed an implementation to my branch. Could you please try it and give some feedback?

git clone https://github.com/brunelli/clipmenu.git

It is very simple. You can have a look at clipdel -h to see what was implemented. I still have to put some examples in there.

I hope to open a PR soon.

Just tried it.

clipmenu | clipdel works great!

clipdel -c does not work for me, it only outputs the current entry

Sorry, should be fixed now.

I've added some examples too.

Yep works. Is it intentional that when piping input into clipdel it doesn't require -d?

Well, there's no sense in printing when reading from stdin. If one wants clipmenu to print the selection it can be done with clipmenu | cat.

I will change the -d description to reflect that.

I guess that makes sense.

A PR is open in #100.

It'd be great to have some people testing it, especially the deleting part, as the logic was rewitten.

As stated, a menu can be used for deletion with clipmenu | clipdel. For more options, read clipdel --help.

I simply use sh -c 'passmenu && clipdel -d "$(xsel -b)"' with an appropriate key binding.

It assumes the password is not a regular expression that will nuke my clipmenu history, but:

1. I set the passwords.
2. No severe damage will result from losing my clipboard history (otherwise, my workflow is wrong).

Yeah, this is reasonable (although storage shouldn't be permanent assuming /tmp is tmpfs, but tmpfs can swap).

The better way would be to just not record them at all. If I added a way to temporarily disable clipmenud's monitoring for N seconds without stopping the daemon, would that work for you?

Yes I think stopping monitoring would be the perfect solution for command line password managers like 'pass'.

Yes, I think disable/stop monitoring would be great

like

passmenu --disable-history 45
pass -c secret/pass

I don't know if could work the same workaround of https://github.com/erebe/greenclip/issues/5

Just to update, in the devel branch there is now a way to temporarily disable clipmenu from collecting clips. For example, I run the following when selecting a clip from pass:

clipctl disable && pass -c foo; clipctl enable

Hopefully this helps with some of the cases in this thread.

Does the current implementation (in the devel branch) allow deleting items from the same menu as selecting an item? Or does it need a separate menu (or command/keybinding) to delete items?

If I've understood correctly (from the comments here), I would need to use 2 different commands (with 2 different keybindings):

• one command/keybinding to paste/output an item from clipmenu
• one command/keybinding to choose an item to delete from clipmenu (piping the output to clipdel)

It would be nice to use a single menu for both, and:

• by pressing Enter, clipmenu would paste/output the item
• by pressing Shift+Delete (or similar), clipmenu would delete the item (and keep rofi/dmenu open).

rofi-calc works like that; a single menu with the ability to either select or delete, with Enter or Shift+Delete respectively. So, it's possible at least with rofi (I haven't looked into how it's done in rofi-calc).

rofi-calc works like that; a single menu with the ability to either select or delete, with Enter or Shift+Delete respectively. So, it's possible at least with rofi (I haven't looked into how it's done in rofi-calc).

Unfortunately dmenu exposes nothing like this, so it would have to be a separate menu. I've personally not had the use for it, though, especially with clipctl disable, but I'd be happy to review a PR. :-)

Apparently, rofi-calc is a Rofi plugin (which are written in C), and the plugins have access to some additional functionality in Rofi. So, this doesn't seem to be possible with either dmenu or rofi -dmenu.

The Shift+Delete keybinding appears to be a Rofi feature, which tells the plugin (or "modi" in Rofi's terms) to delete an item from history, and doesn't seem to be accessible with rofi -dmenu (Shift+Delete exits with code 1, and no output, similar to normally quitting Rofi).

---

However, Rofi also supports custom keybindings (bound to Alt+1, Alt+2, Alt+3, etc. by default). The custom keybindings output normally, but change the exit code (to 10, 11, 12, etc.).

So, one of those custom keybindings could be set to Shift+Delete, and depending on the exit code from Rofi, the output would be sent to:

• xsel (exit code 0)
• clipdel (exit code 10)
• nowhere at all (exit code 1, regular quit without selecting anything).

So, definitely seems possible to implement with Rofi. :)

---

Would you accept a PR for this, if it can only work with Rofi (and not dmenu)? I might work on this later this month (during the holidays), unless someone beats me to it.

EDIT: To clarify, this wouldn't break anything when using clipmenu with dmenu, the delete functionality just wouldn't be there.

I've opened https://github.com/cdown/clipmenu/pull/150, which allows using Rofi's custom keybindings with clipmenu.

I'm using the following script, which I've bound to Super+v:

#!/bin/bash

trap "exit" INT

# Run clipmenu
CM_LAUNCHER=rofi clipmenu -p "Paste" -mesg "Use Shift+Delete to delete an item" \
    -kb-delete-entry "" -kb-custom-1 "Shift+Delete" \
    -kb-accept-alt "" -kb-custom-2 "Shift+Return"

exit_code=$?

case $exit_code in
    0) xdotool key "shift+Insert" ;;
    10) clipdel -d ^"$(xsel -b)"$; "$0" ;;
    *) exit $exit_code ;;
esac

With the above script, I have 3 different options when running clipmenu:

• if I press Return, the selected item is pasted to where my cursor currently is (a bit hackily with xdotool)
• if I press Shift+Return, the selected item is sent to the clipboard ("default" clipmenu behavior)
• if I press Shift+Delete, the selected item is deleted from clipmenu, and the script runs itself again (essentially keeps clipmenu open)

This requires only the small change in the PR.

Rofi script modi would be more useful - could be possible to operate with menu continuoustly, without restarting after each operation - e.g. remove multiple items, one after one, seeing immediate menu change.