cdown / clipmenu Goto Github PK

Hello are there any plans on implementing some simple cli interface to daemon? It would be really useful for scripting and stuff like that.

Hi,

loving clipmenu and have it always running in the background...I noticed that when I use MATLAB, if clipmenud is active, ctrl+c and ctrl+v won't copy and paste text. This happens for any shortcuts I set, not only for the specific combination of ctrl+c and ctrl+v. The only way I can copy and paste text is by highlighting it and then press the middle cursor on mouse...any idea why this happens, why this is specific to matlab and how to overcome this little problem?

Thanks!

This would allow us to grab multiple clipboard selections if another happens while we are running the main block

Cc: @kingcody

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.

Thanks for the performance upgrade!

I have a feature request: It would be great to be able to set a different cache_dir than /tmp using a command line argument. This way one could sync entries with different devices and save them on reboot.

If you close the application from which you copied text, you need to open clipmenu to retrieve the copied text: in other words, you can’t Ctrl-v on a new application if you have closed the one from witch you Ctrl-c.

For example:

I don't remember this happening in the past, but it happens when doing drag selection in Chrome 45.0.2454.85.

clipmenud polls the clipboard every 0.5 seconds (or another interval as configured with the CM_SLEEP environment variable). Unfortunately there's no interface to subscribe for changes in X11, so we must poll.

reference:

https://unix.stackexchange.com/questions/106736/detect-if-mouse-button-is-pressed-then-invoke-a-script-or-command

xev -event button | grep ButtonRelease can monitor mouse ButtonRelease event. But I don't know whether there is any pipe event listener in shell so that clipboard update could be triggered.

However the good news is that xbindkeys is able to bind a shell command with keyboard/mouse event.
For instance, this xbindkeys config will add a new clipboard entry on the event of left button release.

"add_new_entry_with_xsel"
  b:1 + Release

clipmenu will be way much better with this (not really tested the above yet).

I'm certain this is an issue with my environment, but recently clipmenud stopped working with my systems user service. Specifically, it runs, but while it is running none of the selection buffers contain anything and I cannot copy or paste anything. xsel -o outputs nothing and xclip actually gives an error.

Running clipmenud from .xinitrc has the same issues. Running clipmenud from a terminal in X works fine.

I've gone through /proc/$pid/environ when clipmenud is working, and I tried to put all of those variables in the systemd unit. Didn't help.

I'm on archlinux- anyone have any idea what's happening?

For privacy and security, it would be nice to have an explicit limit of how many items are stored in the clipboard, so old are rotated out after a while. This help passwords and other sensitive items from persisting in storage for longer than intended.

Perhaps this feature exists in the source code and I missed it. If it's there, it would be helpful to have it documented.

I noticed these sort of errors when coming out of suspend.

My workaround is a systemd service file like http://ix.io/lca

Sorry, I have dejavu with this. Couldn't find a past issue. Basically I want my default behaviour not to show duplicates when I open clipmenu. Thanks!

Something like that broke all the history:

$ cat ~/Pictures/star.jpg | xclip -i -selection clipboard

I am using arch linux with i3 and pcmanfm.
clipmenu 1.2.1 update broke files copy/paste. I also tried thunar and the problem persists.
If I kill clipmenud the copy/paste are working again.
Did I miss some config option?

Thanks for the great tool!

Sometimes passwords and other sensitive details pass through the clipboard manager and could end up getting logged to disk through this tool, increasing the chance that they are discovered there, or potentially backed up.

This risk can be minimized while also improving performance by defaulting the cache directory to /run/user/$uid if it exists and is writable, and the current value of /tmp as a fallback.

This directory exists as part of the systemd standard and is created as a tmpfs in-memory file system. References:

• https://unix.stackexchange.com/questions/162900/what-is-this-folder-run-user-1000
• https://wiki.archlinux.org/index.php/tmpfs
• man file-hierarchy (on systemd-based systems)

Since /tmp remains a fallback, this change would be backwards compatible. The change would also pair well with the feature to limit the clipboard history, to avoid unbounded memory usage for clipboard storage.

I was wondering if allowing the polling interval of clipmenud to be configured was within the scope of this project?
Currently I have:

--- clipmenu/clipmenud
+++ clipmenu/clipmenud.new
@@ -1,11 +1,29 @@
 #!/bin/bash

+wait=1
+
+while getopts ":w:" opt; do
+  case $opt in
+    w)
+      wait="$OPTARG"
+      ;;
+    \?)
+      echo "Invalid option: -$OPTARG" >&2
+      exit 1
+      ;;
+    :)
+      echo "Option -$OPTARG requires an argument." >&2
+      exit 1
+      ;;
+  esac
+done
+
 cache_dir=/tmp/clipmenu.$USER/
 mkdir -p -m0700 "$cache_dir"

 declare -A last_data

-while sleep 1; do
+while sleep "$wait"; do
     for selection in clipboard primary; do
         if type -p xsel >/dev/null 2>&1; then
             data=$(xsel --"$selection"; printf x)

Your thoughts?

It's a great lightweight tool, but really slows down when copying a single line that is extremely long.
Would like to propose to cut the first N character of the selection:

    first_line=$(sed -n '/./{p;q}' "$file" | cut -c1-100)

After I call clipmenu and select my new clipping it is not there when I past. It reverts to the last text copied.

dmenu 4.5
ubuntu 14.04

Hi,
I use st terminal with the "old clipboard way" patch and I noticed clipmenu would not list anymore older files in list if newest file is empty, this happens when I change window to st with mouse and sometimes dubble click inside, ops selected and copied space.
So I change clipmenud line 40 to [[ $data == [^[:space:]] ]] || continue
this solves my issue and no more accidental empty files created.

Right now, with >5000 clips, it can get fairly slow. It might be better to just store the first line in the filename instead of the MD5, since we can uniquely identify with that too (or at least, we do anyway).

https://github.com/cdown/clipmenu/blob/develop/init/clipmenud.service#L8 assumes DISPLAY=:0 but with the new Optimus setups it can be on :1, hence Environment=DISPLAY=:1 needs to be updated.

Not sure if this variable can be better detected.

http://s.natalian.org/2016-09-28/clipmenu.mp4

Using 05431fe from the develop branch.

My ~/.config/systemd/user/clipmenud.service

Hi,
I find myself copying same stuff over and over and this fills my list, so I'm wondering if it's possible to implement a removal of duplicates and keep only latest timestamped copy.
I'm using "fdupes -qdN /../tmp/clipmenu.user/" and this works as long I exec it standalone, but not inside clipmenud - it keeps the oldest copy not the newest,
(I'll take this up with fdupes dev to delete by timestamp). But maybe there is a nicer way doing this?

How to disable this "feature" to copy everything I select?

Right now if someone does a, a thing, it's going to be annoying that it disappears.

I use rofi as a replacement for dmenu and noticed if more then 8 clips in the list, clipmenu will start when called, selecting the 9th line. Editing dmenu_lines=${CLIPMENU_LINES} solved the selector starting allways from first line. Guess it's a tiny headsup for any rofi users:)
Thanks for a great clipboard alternative!

oh sorry I see it's easy to just edit the clipmenu script and change line 3 to
: "${CM_LAUNCHER=rofi}" then the first keybinding I show below works

I use the hotkey program sxhkd and making a keybinding like
alt + y
clipmenu
works fine but not if I try to use with rofi i.e.
alt + y
CM_LAUNCHER=rofi clipmenu
although the above command typed in terminal works.

It would nice to able to interact with the clipboard directly on Wayland, without the need to run XWayland to proxy traffic through an X server.

The Sway window manager is Wayland-native, and has already implemented a CLI to get the clipboard contents from Wayland. (Looks like swaymsg -t get_clipboard). Perhaps it could serve as inspiration for what's needed here.

• Interact with Wayland clipboard via cli

In #49 (comment) and onwards, @markstos says that the clipboard contents is still being printed. I don't currently repro this, either running as a systemd user service or not.

I use Qtile DM and added to config to run clipmenu on keybinding. Clipmenu starts but selected text doesn't puts into clipboard. If I run it from console - all fine

When I copy from my terminal, I've noticed that sometimes the default sleep of 0.5 is not quick enough to synchronize, leaving my clipmenu-url to act on the wrong URL for example.

Clipmenud's loop needs to be refactored into a function so I can call clipmenu from st directly.

After returning from suspend climenud appears to be running but calling clipmenu is not populated with newly highlighted/copied items

In #49 (comment) and onwards, @markstos reports a problem which I do repro:

% systemctl --user status clipmenud                     
● clipmenud.service - Clipmenu daemon
   Loaded: loaded (/usr/lib/systemd/user/clipmenud.service; disabled; vendor preset: enabled)
   Active: active (running) since Sun 2017-10-29 10:19:04 GMT; 4min 26s ago
 Main PID: 30101 (clipmenud)
    Tasks: 2 (limit: 4915)
   CGroup: /user.slice/user-1000.slice/[email protected]/clipmenud.service
           ├─ 4514 sleep 0.5
           └─30101 /bin/bash /usr/bin/clipmenud

Oct 29 10:19:04 roujiamo systemd[430]: Started Clipmenu daemon.
Oct 29 10:19:04 roujiamo clipmenud[30101]: xsel: error opening logfile /proc/self/fd/2 for writing: No such device or address
Oct 29 10:19:40 roujiamo clipmenud[30101]: xsel: error opening logfile /proc/self/fd/2 for writing: No such device or address
Oct 29 10:20:32 roujiamo clipmenud[30101]: xsel: error opening logfile /proc/self/fd/2 for writing: No such device or address
Oct 29 10:21:19 roujiamo clipmenud[30101]: xsel: error opening logfile /proc/self/fd/2 for writing: No such device or address
Oct 29 10:22:57 roujiamo clipmenud[30101]: xsel: error opening logfile /proc/self/fd/2 for writing: No such device or address

That said, I'm not entirely sure what's happening here, since I don't repro when taking on those namespaces:

% q nsenter -m -p -r -t $(pgrep -ox clipmenud) sudo -i -u cdown
% echo foo > /proc/self/fd/2 
foo

F.e. setfacl -m d:o::0000 /tmp/clipmenu.hashworks

As suggested by @milouse.

Hi,
I'm testing out clipnotify and it works great, but I noticed that while using figaro's password manager there is a setting to copy both user and password on enter, however while using clipnotify I'm only able to capture user but not the password, if I return to sleep it works ok. Unshure how to resolve this, any ideas?

Issue on 3d079ab I've seen a couple of times now whereby I don't get all my selections anymore?

Not sure why this is happening. I added an echo $files and exit to show there is only one file being picked up.

+ files=(/tmp/clipmenu/*)
+ echo /tmp/clipmenu/2015-04-29-13-32-44-f4d5d0c0671be202bc241807c243e80b
/tmp/clipmenu/2015-04-29-13-32-44-f4d5d0c0671be202bc241807c243e80b
+ exit

Also noticed clipmenu: line 25: selections[$first_line]: bad array subscript... think it's unrelated.

@milouse did this in a fork, these should be integrated back into mainline.

I'm measuring with time and pressing enter repeatedly to trigger a dmenu selection. 1.2.2 is a bit slow for me when it's >1sec

/tmp/clipmenu.hendry$ ls -1 | wc -l
397
/tmp/clipmenu.hendry$ time clipmenu

real    0m1.773s
user    0m0.090s
sys     0m0.110s
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$ time clipmenu









real    0m1.727s
user    0m0.130s
sys     0m0.073s
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$
/tmp/clipmenu.hendry$