CopyQ
CopyQ copied to clipboard
hluk
CopyQ not copying all of the time in Kali Linux
Before creating a new issue, see list of known issues.
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)
NOTE: The FAQ page that has the DEBUG log instructions has a typo
Thanks, fixed.
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).
This sounds like it could be an issue with virtual machine software/integration. There has been a few in the past.
I am using VMware Workstation 16 on a Windows 11 host, Kali Linux guest.
So what to do about this?
Thanks,
Robert
Not sure how to fix this. You can try using flatpak version of CopyQ (see https://copyq.readthedocs.io/en/latest/installation.html).
K, flatpak appears to be supported on Kali. I will try
What is the difference between running the .deb version and the flatpak version? "Containerized" app? All app components are within the "container" / sandbox and not reliant on any of the other system libraries?
Thanks!
I have uninstalled the .deb version of CopyQ and installed flatpak and then installed the flatpak version of CopyQ. I have imported a backup which did import my data
Initial virgin install of CopyQ flatpak
CopyQ import
CopyQ import done - note clipboard and clipboard (1). I am aware that clipboard (1) is the contents of my backup clipboard tab. So there are 4 items in the new clipboard tab and a ? quantity for all other tabs (CopyQ does not know until you click on each tab
Click on clipboard (1) tab and we see 6000 items
Note 350 items in the url tab
Removing the clipboard tab so that the current clipboard (1) tab can become the main clipboard tab
clipboard tab deleted
At this point I am usually able to rename the clipboard (1) tab to clipboard but t is not allowed at this time so I shut down CopyQ (File / Exit)
I renamed the clipboard (1) tab to clipboard in the copyq.conf file and now the data is gone (I had, before starting all this documentation on this this evening, been able to rename the tab and had the same results. I have done this countless times with the .deb version of the app and it works without issue / as expected. Also note that the contents of the url tab is now empty. Other tabs appear to still have their data.
Rename the tab back to clipboard (1) in the copyq.conf file and the data is back in that tab but the url tab data is still missing
Also note that the import did not appear to import my settings properly. Example - the tab labeled clipboard (1) should have a Maximum number of items set to 6000 and it is set to the default
Also note that while it appears that my list of commands appears to have been imported, including the Backup On Exit, the backup is not doing anything. I have shut CopyQ down many times since starting this and there are no new backups. The newest backup is about 5 hours ago.
I deleted all the data and set the logging to DEBUG (you need to document how to do this with a flatpak install if it is not already) and imported the backup and then renamed the new, empty clipboard tab to clipboard-old and then I was able to rename the clipboard (1) tab to clipboard and all my data appears to be there now (in both the clipboard and the url tabs).
Now to close the program and reopen it and see what happens. Both the clipboard and the url tabs are now empty
The DEBUG logs that I configured do not appear to exist
A find for .log files inthe flatpak directory
A find for the named DEBUG log file in any of my home directory
So far not really liking flatpak very much ...
I'm fine with trying the flatpak version to see if it will solve my issues, but it has created a number of new challenges.
Given this information (I would have happily supplied the DEBUG logs but ...) what do I do next?
HELP Please!
Thanks!
Robert
Well after all that it looks like I figured out what the issue was / is. The line below in the copyq.config file appears to have been the culprit. All of the tabs set to sync were the ones where the data was getting deleted. I removed the entries after the equal sign and the data is not getting deleted any more.
itemsync\sync_tabs=&clipboard, /home/rstrom/Dropbox/CopyQ_Sync/clipboard, &url, /home/rstrom/Dropbox/CopyQ_Sync/url, Nmap, /home/rstrom/Dropbox/CopyQ_Sync/Nmap
That's good!
Now the not-so-good / really bad. The very first item that I went to copy, the line highlighted in the screenshot below did not copy. I copied it twice. Once by right clicking and selecting copy and the second time by selecting Edit > Paste
More data ...
- I selected two URL's in the Firefox browser and copied them and they copied to the url tab
- I selected text on one of the pages in the browser, it did not copy
- I selected text in Geany and right clicked to copy and nothing copied
- A work-around that I had is not working. If I use the command:
cat ~/.config/copyq.bak/copyq.conf | grep sync | xclip
That would normally copy the results of the text from the terminal to the clipboard and then CopyQ. This is no longer happening. Not only is the text not copying to CopyQ, but it is also not actually on the clipboard.
- If I turn CopyQ off then I can run the same command the text is now on the clipboard
- If I start xfce4-clipman (already installed in the Kali build) and select text in the terminal and copy it the text is stored in the clipman history
- If I select text in the same web page previously tested in Firefox the text is copied to the clipman history
- If I have CopyQ up and running and have Clipman up and running at the same time and select text in the terminal, text in the web browser, text in Geany all of it is copied to the clipboard history and stored
Other known issues that I am seeing in flatpak CopyQ
- CopyQ flatpak is set to Autostart and that is not working
- Backup On Exit not working (it is checked / selected)
copyq.conf file attached copyq-commands.ini file attached copyq_config_files.zip
I took a snapshot of my Kali VM before installing flatpak and the CopyQ version of flatpak and I took another snapshot with flatpak and flatpak CopyQ installed. I am currently reverted back to the deb version of CopyQ VM snapshot.
Some pretty serious issues here, at least from my perspective. Don't get me wrong, I love the program. All the features and functions are great but at a bare minimum I need the most basic function of copy, store what I copied, and then let me select it and paste it and this is not working reliably in either scenario, with flatpak being really bad for other reasons on top of the copy and paste issues.
What next?
Robert
Just as a test I uninstalled xclip and tested to see if that made any difference (this is in the deb install environment) and it did not. As a precaution I rebooted and tested again. Still no difference.
I have reinstalled xclip
Touching base. Any questions, comments, suggestions, updates to try? Anything needed from me here on this issue?
Thanks
I haven't been able to respond to issues in a while and there is too much to unpack here.
I tested config files you provided and they seem to work (at least on Fedora 36).
From the last screenshot it seems that CopyQ detected the copy operation from the terminal, it just did not add it to the clipboard tab. Is that correct?
If I have CopyQ up and running and have Clipman up and running at the same time and select text in the terminal, text in the web browser, text in Geany all of it is copied to the clipboard history and stored
This is very strange. There is nothing that would require CopyQ to run additional clipboard manager under X11.
From the last screenshot it seems that CopyQ detected the copy operation from the terminal, it just did not add it to the clipboard tab. Is that correct?
Yes, that is correct. I saw this exact behavior again yesterday.
The configuration that I have having the huge issue with is a Windows 11 host running Kali Linux 2022.2 using XFCE desktop inside VMware Workstation 16.2.3. I am taking the OSCP PEN 200 course and have been using this setup very heavily and the documentation of what I am doing relies on tons of copying and pasting both within the VM itself and between the VM and the host OS.
This is very strange. There is nothing that would require CopyQ to run additional clipboard manager under X11.
Agreed but right now it is my fallback for when CopyQ does not capture the snippet that I need.
I love CopyQ but this is very frustrating.
Is your Fedora a bare metal system or a VM?
I have a couple of other Kali VM's that I have (two are using KDE). They are not my day to day Kali instances but I will try to determine if they are also experiencing the same issue. I also have two bare metal systems running Pop!_OS (based on current Ubuntu 22.04 LTS) that I use. Both have CopyQ installed but again, the copy and paste withing the Kali instance is very heavy. Clips of code from the terminal and lots of screenshots. None of my other setups have this amount of copying and pasting.
Is your Fedora a bare metal system or a VM?
It's running on a bare metal.
I think there could be some automated command enabled (in Command dialog - F6 shortcut) that rejects the clipboard so it does not get into the list.
You can try running clean instance of CopyQ to see if it can store the clipboard (start new clean session with for example copyq -s test).
copyq -s test appears to work / that's GREAT .. .except ... I have removed every single F6 command from my instance and then tried copying and nothing is getting captured.
When I delete all of the commands, what appears to be a predefined set of commands is automatically populated. So at this time those are the only commands that are currently in the F6 command list.
[image: image.png]
So, it seems like you are on the right track. Just need to figure out how to get copying again with all of my stored clips and where to go from there to get me some commands back.
Thanks!
On Mon, Jun 13, 2022 at 7:06 AM Lukas Holecek @.***> wrote:
Is your Fedora a bare metal system or a VM?
It's running on a bare metal.
I think there could be some automated command enabled (in Command dialog - F6 shortcut) that rejects the clipboard so it does not get into the list.
You can try running clean instance of CopyQ to see if it can store the clipboard (start new clean session with for example copyq -s test).
— Reply to this email directly, view it on GitHub https://github.com/hluk/CopyQ/issues/1975#issuecomment-1153961571, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYXCDPHIXZBNYAYZ4N4N4DVO454LANCNFSM5UZC5IKA . You are receiving this because you authored the thread.Message ID: @.***>
Clarification on the previous reply. copyq -s test works great ... and then I tried to run with my instance and remove all of the commands and that did not work.
But ...
Looks like another step forward in the right direction.
I launched the copyq -s test and then imported my backup without the commands and that did not work.
I deleted the copyq-test instance and then launched again and imported a backup without the commands and without the configuration and that appears to be successful in as much as I have tested in a few minutes.
One issue I see with this is that the default maximum for the *clipboard *tab (I believe any tab) is 200, so I lose the rest of my 6k clips from my current clipboard tab (I also had 300 in a URL's tab but I could live without that).
Think I just got that figured out. I exported the clipboard tab from the old instance and then imported it to the new instance and then deleted the clipboard tab and renamed the clipboard (1) tab to clipboard and got past that point.
I may be good to go now. I am going to move the copyq-test instance back to the standard copyq instance and proceed from there. I have all my old backups so I will be able to revert if needed.
I will start adding back some of the commands and see where that takes me.
Thanks for thinking of that one little thing that led me down this troubleshooting path. Not sure about you, but it seems like something in the configuration was corrupted.
CopyQ ... and its developers, do rock! ;-)
Thanks,
Robert
On Mon, Jun 13, 2022 at 7:06 AM Lukas Holecek @.***> wrote:
Is your Fedora a bare metal system or a VM?
It's running on a bare metal.
I think there could be some automated command enabled (in Command dialog - F6 shortcut) that rejects the clipboard so it does not get into the list.
You can try running clean instance of CopyQ to see if it can store the clipboard (start new clean session with for example copyq -s test).
— Reply to this email directly, view it on GitHub https://github.com/hluk/CopyQ/issues/1975#issuecomment-1153961571, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYXCDPHIXZBNYAYZ4N4N4DVO454LANCNFSM5UZC5IKA . You are receiving this because you authored the thread.Message ID: @.***>