Selecting an item from the history does not override my current clipboard (i3wm)

[Aiku1]

I installed clipmenu and clipnotify on Arch installation using the *-git packages in AUR

If I open the clipmenu menu and press enter on an item, nothing changes. Upon hitting CTRL+V or Shift+Insert I still paste the old element I have in my clipboard.

Can't really understand why, any suggestion?

[cdown]

Can you please show bash -x "$(type -p clipmenu)", where you select a clip and this problem still happens?

[cdown]

(also, there are no clipmenu-git or clipnotify-git packages in AUR)

[Aiku1]

@cdown

bash: clipmenu is /usr/bin/clipmenu: No such file or directory

[Aiku1]

@cdown I'm sorry, I got confused with something else. There aren't any *-git packages of those but they are in the AUR, that's what I meant

[cdown]

@Aiku1 That's not what type -p clipmenu does, did you just do type clipmenu?

Either way, bash -x /usr/bin/clipmenu

[Aiku1]

@cdown I executed that command from within zsh, maybe that's the reason.

Anyway, here's what you asked

+ : dmenu
+ : /run/user/1000
+ major_version=5
+ shopt -s nullglob
+ cache_dir=/run/user/1000/clipmenu.5.usr
+ cache_file_prefix=/run/user/1000/clipmenu.5.usr/line_cache
+ [[ '' == --help ]]
+ [[ '' == -h ]]
+ [[ dmenu == rofi ]]
++ cat /run/user/1000/clipmenu.5.usr/line_cache_primary /dev/null
++ LC_ALL=C
++ sort -rnk 1
++ cut '-d ' -f2-
++ awk '!seen[$0]++'
++ dmenu -l 8
+ chosen_line='foo bar'
+ [[ -n foo bar ]]
++ cksum
+ file='/run/user/1000/clipmenu.5.usr/2773411705 18'
+ [[ -f /run/user/1000/clipmenu.5.usr/2773411705 18 ]]
+ for selection in clipboard primary
+ xsel --logfile /dev/stderr -i --clipboard
+ for selection in clipboard primary
+ xsel --logfile /dev/stderr -i --primary

I've noticed that running clipmenu this way does actually work like expected, for some reason. (just clipmenu works too) Adding the same command as a keybind still doesn't work, for some other reason.

[cdown]

How are you setting up your keybind? Probably wherever you set it doesn't set up $DISPLAY correctly

[Aiku1]

In i3 config (~/.config/i3/config) i have bindsym $mod+Insert exec clipmenu, with $mod being the Windows key

EDIT : I found a workaround by setting clipmenu to be run from a terminal (urxvt -e clipmenu) and it actually works very well. Only problem is the terminal doesn't close upon the spawn of the clipmenu menu and it kind of messes up all the other windows I have open. Any tip to close the terminal as soon as the menu is spawned would be great, since it would fix all my problems without further tinkering.

[Aiku1]

After a few rounds of trial and error, I finally managed to get it to do what I want, by setting this to be executed when I call my shortcut : urxvt -e sh -c "nohup clipmenu".

It's not pretty and if your computer isn't really fast the terminal popping and disappearing might be distracting but it's still better than nothing, I guess.

@cdown if you can provide a better solution I will be glad to try it!

[cdown]

If that works, it's almost certainly some problem with $DISPLAY not being set correctly.When clipmenu is open, what's the output of tr '\0' '\n' < /proc/"$(pgrep -nx clipmenu)"/environ?

[Aiku1]

This :

LC_ALL=en_US.UTF-8
_=/usr/bin/nohup
LANG=C
GDM_LANG=C
DISPLAY=:0
COLORTERM=rxvt
USERNAME=usr
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XDG_VTNR=2
XDG_SESSION_ID=c2
USER=usr
DESKTOP_SESSION=i3
PWD=/home/usr
HOME=/home/usr
XDG_SESSION_TYPE=x11
XDG_SESSION_DESKTOP=i3
DESKTOP_STARTUP_ID=i3/urxvt/1016-42-arch_TIME11054281
GTK_MODULES=canberra-gtk-module
MAIL=/var/spool/mail/usr
WINDOWPATH=2
TERM=xterm-256color
SHELL=/bin/zsh
XDG_CURRENT_DESKTOP=i3
COLORFGBG=default;0
SHLVL=2
XDG_SEAT=seat0
WINDOWID=10485769
GDMSESSION=i3
LOGNAME=usr
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
XAUTHORITY=/run/user/1000/gdm/Xauthority
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:<some other folders>

I tried both ways (using rofi and using my solution) and except for these differences

> _=/usr/bin/nohup
> COLORTERM=rxvt
> DESKTOP_STARTUP_ID=i3/urxvt/1016-47-arch_TIME11965617
> TERM=xterm-256color
> COLORFGBG=default;0
> SHLVL=2
< SHLVL=1
> WINDOWID=10485769
< _=/usr/bin/rofi

(< is rofi launch, > is "script" launch) they're the same (i used diff to compare them).

Do you see anything that might suggest a problem?

[cdown]

$DISPLAY looks ok. What error output is there from clipmenu when run from the keybinding? Presumably i3 stores this somewhere.

None of those environment variables should change anything, so my best guess is that there is some misconfiguration around X auth.

[Aiku1]

From the only i3 logs I could find (i3-dump-log) I can't really see anything different from any other shortcut

What do you suggest to fix that misconfiguration?

[cdown]

I'll try and repro when I have time, but this is almost certainly an i3 misconfiguration. I don't use i3, so I can't really guide you towards what to do without reproing.

[Aiku1]

It's fine, I can still (kind of) use it like this.

I appreciate the effort!

[cdown]

Closing for now, feel free to report back if you find more information. :-)

[kaihendry]

Morning, I have experienced the same issue as @Aiku1 after upgrading to 5.0.

After selecting the clipboard selection in dmenu, it doesn't very occassionally get set or is in the wrong order (like off by one error). But it's intermittent. Unable to reproduce. So very odd.

[kaihendry]

I think it has something to do how long it is and whether the selection is 2 lines or not.

[cdown]

@kaihendry I think fixing #67 will fix this. This bug could have caused selections to become off-by-one. Not sure if it's related to this issue though.

[fikovnik]

I have the same problem and I think it is related to this:

xsel: error opening logfile /dev/stderr for writing: No such device or address

If running directly from i3, no stderr will be associated. Removing the --logfile from clipmenu fixes it.

[cdown]

Are you running the latest version of clipmenu? This should not be possible with https://github.com/cdown/clipmenu/blob/83289bb94d60730e59ad5e5aa94d13fdea8aa96e/clipmenud#L25-L33

[fikovnik]

I have: aur/clipmenu 5.3.0-1 - is there a newer one?

[cdown]

No, that's the latest. Can you show me stat -L /dev/stderr from the affected environment?

[fikovnik]

stat -L /dev/stderr                                                                                                               ✓
  File: /dev/stderr
  Size: 0               Blocks: 0          IO Block: 1024   character special file
Device: 17h/23d Inode: 6           Links: 1     Device type: 88,3
Access: (0620/crw--w----)  Uid: ( 1000/ krikava)   Gid: (    5/     tty)
Access: 2018-05-07 20:23:58.058561661 +0200
Modify: 2018-05-07 20:23:58.058561661 +0200
Change: 2018-05-03 01:17:22.058561661 +0200

[fikovnik]

stat -L /dev/stderr                                                                                                               ✓
  File: /dev/stderr
  Size: 0               Blocks: 0          IO Block: 1024   character special file
Device: 17h/23d Inode: 6           Links: 1     Device type: 88,3
Access: (0620/crw--w----)  Uid: ( 1000/ krikava)   Gid: (    5/     tty)
Access: 2018-05-07 20:23:58.058561661 +0200
Modify: 2018-05-07 20:23:58.058561661 +0200
Change: 2018-05-03 01:17:22.058561661 +0200

[cdown]

That that's a character device almost certainly indicates this wasn't run from the affected environment, but from a terminal.

I assume stat -L "$(readlink -f /dev/stderr)" shows a pts in where you ran that, but if you're getting "no such device or address", it's almost certainly not in the affected one.

[fikovnik]

So I wrapped clipmenu to a script that calls stat -L and bound that script to a key in i3. Here it is:

  File: /dev/stderr
  Size: 0           Blocks: 0          IO Block: 4096   socket
Device: 9h/9d   Inode: 17373       Links: 1
Access: (0777/srwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1970-01-01 01:00:00.000000000 +0100
Modify: 1970-01-01 01:00:00.000000000 +0100
Change: 1970-01-01 01:00:00.000000000 +0100
 Birth: -

[cdown]

Yeah, in this case, this is a symlink to a socket, which doesn't work on Linux (at least, you can't directly write to it). [[ -f "$(readlink "$file")" ]] should detect this... I really don't know why it isn't. Can you wrap with namei /dev/stderr; stat -L "$(readlink -f /dev/stderr)"? :-) Thanks!

[fikovnik]

Sure:

from namei:

f: /dev/stderr
 d /
 d dev
 l stderr -> /proc/self/fd/2
   d /
   d proc
   l self -> 16740
     d 16740
   d fd
   l 2 -> socket:[17373]
       socket:[17373] - No such file or directory

stat fails with:

stat: cannot stat '/proc/16741/fd/socket:[17373]': No such file or directory

[cdown]

Ah shit, somehow I missed that this code is missing -m :/

Let me go fix that. Thanks for the report.