hluk / hluk/CopyQ

CopyQ not copying all of the time in Kali Linux

Open
#1,975 15 comments 0 reactions 0 assignees View on GitHub
bug X11
Dominant language
C++
Stars
12.3k
Forks
593
Avg merge
2d 8h
Merged PRs (30d)
9

Description

Before creating a new issue, see list of [known
issues](https://copyq.readthedocs.io/en/latest/known-issues.html).

**Describe the bug**

I have an instance of CopyQ running on my Kali Linux and it will mysteriously just stop copying selected text in both the terminals (I am using both the stock QT Terminal and the Terminator terminal) and in various GUI applications (one example is the Geany IDE / text editor).

The log file included was specifically only running while I was moving from terminal to terminal and to the Geany application and selecting text within each new window and copying the text. In almost every situation the text did not appear in the CopyQ clipboard tab as expected. I could, however, move the cursor to an application outside of the Kali virtual machine (Joplin) and paste the text that I just copied from the Geany application in the Kali VM (yet the text appears to be nowhere in CopyQ itself).

I have found that if CopyQ will not copy text that I want copied from a terminal window I can place the text in quotes and place the echo command in front of the quoted text and then pipe the echoed text to the **xclip** program and the text will then appear in the CopyQ clipboard tab. Example:

```
echo "find ./ -type d \( -path ./QNAPMyDocs -o -path ./.vscode \) -prune -o -iname '*.py' -print" | xclip
```

I grepped to see if there were any other clipboard processes (simple grep just looking for the word **clip**). Here are the results:

```
┌──(rstrom㉿kali-2022)-[~]
└─$ ps aux | grep clip
rstrom 460419 0.7 0.8 495368 32740 pts/6 Sl+ 14:53 1:28 xfreerdp /cert-ignore /compression /u:offsec /p:*** /w:1366 /h:768 /v:192.168.167.10 /smart-sizing +auto-reconnect +clipboard
rstrom 509882 0.0 1.2 300580 48672 ? Sl 17:57 0:00 /usr/bin/copyq --clipboard-access monitorClipboard
rstrom 513045 0.0 0.0 6428 2340 pts/3 S+ 18:09 0:00 grep --color=auto clip

┌──(rstrom㉿kali-2022)-[~]
└─$
```

**To Reproduce**
Steps to reproduce the behavior:

Described above

**Expected behavior**
A clear and concise description of what you expected to happen.

Copy all text copied from terminals and GUI program to the CopyQ clipboard and save them there until deleted or they roll off due to the clipboard tab exceeding the maximum number of clips configured.

**Screenshots**
If applicable, add screenshots to help explain your problem.

Really no screenshots to be taken of this. I am including the DEBUG logs.

**NOTE: The FAQ page that has the DEBUG log instructions has a typo**
https://copyq.readthedocs.io/en/latest/faq.html#how-to-enable-logging

These instructions have an incorrect slash (it is a backslash and should be a forward slash) in the third line:
```
copyq exit
export COPYQ_LOG_LEVEL='DEBUG'
export COPYQ_LOG_FILE="$HOME\copyq.log"
echo "Logs will be written to $COPYQ_LOG_FILE"
copyq
```

The commands should be (with the third line having a forward slash for Mac and Linux):
```
copyq exit
export COPYQ_LOG_LEVEL='DEBUG'
export COPYQ_LOG_FILE="$HOME/copyq.log"
echo "Logs will be written to $COPYQ_LOG_FILE"
copyq
```

**Version, OS and Environment**
(Get details from `copyq version` command if possible.)
- Application Version [e.g. 3.7.2]
- OS [e.g. Windows]
- Desktop environment, window manager (if applicable)

CopyQ 6.1.0

```
┌──(rstrom㉿kali-2022)-[~/exploits]
└─$ cat /etc/os-release 130 ⨯
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2022.1"
VERSION_ID="2022.1"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
```

Here's what `copyq version` says
```
┌──(rstrom㉿kali-2022)-[~]
└─$ copyq version
CopyQ Clipboard Manager 6.1.0
Qt: 5.15.2
KNotifications: 5.90.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Kali GNU/Linux Rolling
```

The Kali Linux is using the stock window manager (XFCE I believe)

I ran these commands to see if X11 or Wayland is being used. It looks like it is X11

```
┌──(rstrom㉿kali-2022)-[~]
└─$ loginctl
SESSION UID USER SEAT TTY
2 1000 rstrom seat0

1 sessions listed.

┌──(rstrom㉿kali-2022)-[~]
└─$ loginctl show-session 2 -p Type
Type=x11
```

**Additional context**
Add any other context about the problem here.

FYI - the last clip from the Kali VM did copy and make it to CopyQ (it's in the DEBUG logs if that helps to define what worked and what did not)

[copyq.log](https://github.com/hluk/CopyQ/files/8598101/copyq.log)

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.