Open cytopia opened 6 years ago
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:
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
:
ent
?)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):
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
).
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:
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):
clipmenu
clipmenu
(piping the output to clipdel
)It would be nice to use a single menu for both, and:
Enter
, clipmenu
would paste/output the itemShift+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)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
:
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.
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
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 :-)
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.