Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Menu to delete clipboard entries #57

Open
cytopia opened this issue Dec 19, 2017 · 36 comments
Open

Menu to delete clipboard entries #57

cytopia opened this issue Dec 19, 2017 · 36 comments

Comments

@cytopia
Copy link

cytopia commented Dec 19, 2017

Hi there,

just tried out your tool. Great work 👍

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.
@cdown
Copy link
Owner

cdown commented Dec 19, 2017

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?

@cytopia
Copy link
Author

cytopia commented Dec 19, 2017

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:

screenshot 2017-12-19 19-13-15 selection

@cdown
Copy link
Owner

cdown commented Dec 19, 2017

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.

@cytopia
Copy link
Author

cytopia commented Dec 19, 2017

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)";

@cdown
Copy link
Owner

cdown commented Feb 19, 2018

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

@cytopia
Copy link
Author

cytopia commented Feb 20, 2018

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

@cdown
Copy link
Owner

cdown commented Feb 20, 2018

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

@clinta
Copy link

clinta commented Feb 20, 2018

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

@cytopia
Copy link
Author

cytopia commented Feb 27, 2018

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.

@cdown
Copy link
Owner

cdown commented Feb 28, 2018

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.

@cdown
Copy link
Owner

cdown commented Mar 12, 2018

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

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

@stef204
Copy link

stef204 commented Apr 3, 2018

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

@cdown
Copy link
Owner

cdown commented Apr 22, 2018

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

@cdown cdown changed the title wish: be able to remove specific items manually (such as passwords) Menu to delete clipboard entries Apr 22, 2018
@GSI
Copy link

GSI commented Nov 30, 2018

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;

@GSI
Copy link

GSI commented Nov 30, 2018

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/* :)

Repository owner deleted a comment from kryptonite52965 Dec 6, 2018
Repository owner deleted a comment from kryptonite52965 Dec 6, 2018
@cdown
Copy link
Owner

cdown commented Dec 6, 2018

(deleted spam.)

@brunelli
Copy link

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 #57 (comment).

@GladOSkar
Copy link

GladOSkar commented Jan 11, 2019

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?

@brunelli
Copy link

brunelli commented Jan 11, 2019

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.

@GladOSkar
Copy link

GladOSkar commented Jan 11, 2019

Just tried it.

clipmenu | clipdel works great!

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

@brunelli
Copy link

Sorry, should be fixed now.

I've added some examples too.

@GladOSkar
Copy link

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

@brunelli
Copy link

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.

@GladOSkar
Copy link

I guess that makes sense.

@brunelli
Copy link

brunelli commented Jan 17, 2019

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.

@memeplex
Copy link

memeplex commented Mar 6, 2019

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

@Schueni1
Copy link

Schueni1 commented Oct 23, 2019

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

@ghost
Copy link

ghost commented Nov 9, 2019

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

cdown added a commit that referenced this issue Mar 25, 2020
This allows avoiding having to delete after the fact for things like
issues #57 and #98.

Why have this over just stopping clipmenud? Well:

1. Stopping clipmenud should usually be an init system action, but we
   are init-system agnostic. If we just exit, we don't have a way of
   reliably starting again.
2. Even if we *do* do it using the init system, we don't want some
   things (like a lingering xsel which owns the selection for
   CM_OWN_CLIPBOARD) being killed as well.
3. This is a nicer interface for things like password managers to stop
   clipmenu rather than stopping clipmenu entirely.
cdown added a commit that referenced this issue Mar 25, 2020
This allows avoiding having to delete after the fact for things like
issues #57 and #98.

Why have this over just stopping clipmenud? Well:

1. Stopping clipmenud should usually be an init system action, but we
   are init-system agnostic. If we just exit, we don't have a way of
   reliably starting again.
2. Even if we *do* do it using the init system, we don't want some
   things (like a lingering xsel which owns the selection for
   CM_OWN_CLIPBOARD) being killed as well.
3. This is a nicer interface for things like password managers to stop
   clipmenu rather than stopping clipmenu entirely.
@cdown
Copy link
Owner

cdown commented Mar 26, 2020

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.

@kankaristo
Copy link
Contributor

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

@cdown
Copy link
Owner

cdown commented Dec 7, 2020

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

@kankaristo
Copy link
Contributor

kankaristo commented Dec 7, 2020

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.

kankaristo added a commit to kankaristo/clipmenu that referenced this issue Dec 17, 2020
This change is related to cdown#57 (comment).

If `clipmenu` "preserves" the exit code from the launcher (exits with the same code as the launcher), the exit code's from Rofi's custom keybindings can be used with `clipmenu`.

For example, I'm using the following script 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)

In order for this to work, the only change needed in `clipmenu` is to preserve the exit codes from the custom keybindings.
@kankaristo
Copy link
Contributor

I've opened #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.

cdown pushed a commit that referenced this issue Dec 19, 2020
This change is related to #57 (comment).

If `clipmenu` "preserves" the exit code from the launcher (exits with the same code as the launcher), the exit code's from Rofi's custom keybindings can be used with `clipmenu`.

For example, I'm using the following script 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)

In order for this to work, the only change needed in `clipmenu` is to preserve the exit codes from the custom keybindings.
@nick87720z
Copy link

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.

@zefr0x
Copy link

zefr0x commented Jan 26, 2023

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.

It is a simple rofi script:

#!/usr/bin/bash
# A rofi bash script to delete entries in clipmenu.

if [[ $ROFI_RETV = 1 ]]; then
    clipdel -d "^${@}\$"
fi

CM_LAUNCHER='rofi-script' clipmenu

@cdown
Copy link
Owner

cdown commented Apr 9, 2024

clipdel is now in C, it should be very easy to add a menu mode which uses the same logic as clipdel, and the main logic can just be shared between clipdel{,menu}. PRs welcome :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.