astrand / xclip Goto Github PK

$locate Atoms.h|grep X11
/usr/local/include/X11/Xmu/Atoms.h

$ ./configure -x-includes=/usr/local/include/X11/
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for X... libraries /usr/local/lib, headers /usr/local/include
checking whether -R must be followed by a space... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for strip... strip
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking X11/Xmu/Atoms.h usability... no
checking X11/Xmu/Atoms.h presence... no
checking for X11/Xmu/Atoms.h... no
configure: error: *** X11/Xmu/Atoms.h is missing ***

Reported by: eitanadler

Original Ticket: xclip/bugs/3

I’m attaching a patch that fixes the VPATH build (IOW where builddir != srcdir).

Reported by: yselkowitz

Original Ticket: xclip/patches/1

in gedit, copy some text
go to terminal and type
ls -la | xclip

go back to gedit
then middle click -> get what xclip copied
ctrl+v in gedit -> get whatever you copied initially

go back to terminal
then middle click -> get what xclip copied
ctrl+v in gedit -> get whatever you copied initially

how can i get xclip to be consistent about putting whatever it copies into the same clipboard as gedit?

I use xclip every day and have no complaints. Until recently when I tried to paste into java app. You can fire sample java text field from this page:
http://download.oracle.com/javase/tutorial/uiswing/components/textfield.html (click on Launch)

What I tried:

1. Filled all 3 buffers (p, s, c) with a text, pasting in java is not possible (remember to use Shift-Ins)
2. Watched the xclip -o after copying from java app (Ctrl-Ins): p and c got filled. xclip --selection secondary remains in active processes.
3. Copying/pasting between java and other windows (e.g. gedit, firefox) works like a charm

I am on Debian Linux with openbox. package xclip melds 0.08-8 (xclip itself has no --version option).
Do you experience same problems in your environment?

Reported by: jarekczek

Original Ticket: xclip/bugs/7

This works and prints 'hello':
$ echo hello | xclip
$ xclip -o
hello

Pasting in a graphical application doesn't work. Here I get the old content, before 'hello' was copied the way shown above.
But it works the other way around. A text copied from a website can be printed out on a console properly using 'xclip' command.

Can anyone confirm this?

Thanks,
Andreas

Reported by: *anonymous

Original Ticket: xclip/bugs/4

man pages are installed without having to issue make install.man despite what docs say.

so I have script that begins with something very much like

#!/bin/bash
echo debug 1
var="$(xclip -o)"
echo debug 2
echo "$var"
#do something with var.

now 95% of the time it works just fine exiting in less than a second and actually doing something useful, but sometimes it hangs during xclip (hours or days If i do not notice and kill it sooner). Now I do not think the problem is with xclip ( I think it is probably a problem with the X server or window manager but so far I have not been able to track it down), but It would be nice if I could set a timeout for reading the clipboard so I could add error handling to the script.

My passwordmanager used 'xclip -l 1 -quiet' to put the username (and after exiting) the password on the clipboard for the browser to read.

New browsers generate a multitude of paste events for one paste. -l 1 is not useful, and since the number of paste events needed for one paste differs between applications, I thought of something else.

This patch implements -wait (or -w). Eg: 'xclip -w 500 -quiet', this waits indefinately for the first paste event, after that it waits 500 msec for the next one. If the timer expires, xclip exits.

Reported by: rikatsneldotit

Original Ticket: xclip/patches/6

I am debugging an issue with copying screenshot to clipboard and I need to check which selections are no empty and if they contain binary screenshot data. It would be cool if xclip could give this info, and maybe use file or another method to give the detailed info. Maybe there is another tool for that?

I would expect this:

$ xclip --inspect
PRIMARY: empty
SECONDARY: text 209 bytes (type not detected)
CLIPBOARD: binary 4023 bytes (PNG)

Sometimes I need to xclip -out something that is in the clipboard. I constantly keep looking up the names of the parameters: -selection clipboard, and it's also too long to type.

I have found (through code inspection) that xclip -o -se c works, too. It would be great if this was documented in the man page; bonus points for a parameter -clipboard (abbrev. -c) ;-)

Reported by: kirillmueller

Original Ticket: xclip/feature-requests/2

The INSTALL file says "if you can compile any X apps at all, you'll be able to compile xclip". That doesn't appear to be quite true (at least on my stock Ubuntu 16.04 platform).

I got it compiling by running the following (after judicious running of apt-file to find out what might work):

sudo apt install libx11-dev
sudo apt install libxmu-headers
sudo apt install libxt-dev
sudo apt install libxmu-dev

I'm not sure if all of these are necessary, or whether one of the later ones might be sufficient to include one of the earlier ones.

The '-loops' feature suggests that you can control how many times the selection can be pasted, but depending on what window you're pasting into, it needs multiple iterations of the loop. In other words, some windows need '-loops 2' or even '-loops 3' to paste the selection one time.

I submitted pull #72 that 'dloop' should be incremented only on the non-target version of XChangeProperty() (the one using 8-bits) thinking that the whole selection was fully pasted into the window on that call. However I found on some OS and window configurations that didn't hold true. Using Debian 9 and FireFox for example, trying to paste a selection into the address bar requires several calls to the XChangeProperty via targets, and two calls to XChangeProperty with non-target 8-bit version of the call. Therefore if '-loops' was set to '1' it would not get pasted into the address bar.

I'm not sure if I'm just misunderstanding the purpose of the '-loops' feature or if it's just not working correctly, but if it is supposed to limit the amount of times the selection can be pasted, it needs to be able to more accurately count when a selection has actually been pasted despite the discrepancies in how many times xcin() and its associated XChangeProperty() calls are entered.

I'm wondering if there is a way to examine the window property and compare it with what is in the selection buffer in xclip, and only increment 'dloop' once they're both equal?

Many distributions (e.g. OpenSuse) still use a prehistoric version 0.12 and lack access to many useful features released after 2007, for example support for -t image/png. (hwangcc23@d7e6f23)

Please release current code as 0.13 so everyone gets access to the recent features. It's been simply too long since the previous release.

According to the man page the -filter option should send stdin back to stdout unmodified. When the -rmlastnl option is enabled the data written to stdout is missing that last newline.

As a workaround I'm using sed to add a newline to the last line after xclip in a pipeline but this had the undesired effect of adding a newline even when there wasn't one there in the first place.

Addionally I noticed the -filter option is not shown on the "xclip -help" output.

no matter what i tried, copying videos to the clipboard didnt work.

xclip -selection clipboard -t video/mp4 -i video.mp4
cat video.mp4 | xclip -i -selection clipboard
xclip -sel clip video.mp4

am i doing something wrong? or is this a bug?

im using

OS: Manjaro Linux x86_64
Kernel: 5.2.21-1-MANJARO
Windows Manager: AwesomeWM

first of all: thank you very much for your work on xclip - a really great tool that I'm using
heavily.

The only thing that I was always missing is the possibility to optionally remove a newline
character if it is the very last one:

E.g. if I copied the date to the clipboard with
date | xclip
and wanted to tweak it at the following line of the bash, the following happened:

philipp@rigel:$ date | xclip
philipp@rigel:$ Sam Aug 25 18:11:14 CEST 2012
bash: Sam: Kommando nicht gefunden.
philipp@rigel:~$

Of cause that was because the date command generates a newline character at the very end, xclip
copied it correctly to the clipboard and after inserting it to the bash with Ctrl+Insrt the
newline character made the bash executing it immediately.

Recently I realized that there is a "workaround" for that: use "echo -n $(command) | xclip", e.g.:

philipp@rigel:$ echo -n $(date) | xclip
philipp@rigel:$ Sam Aug 25 18:14:47 CEST 2012

That works just fine. Now I could (and did) define a bash function that wraps xclip and does
the above. However, I don't think that other users will find this or a similar solution easily.

So I started to investigate, how much work it would be to add an option -r to xclip that
removes the very last newline character, if one is present. It was very easy to do and I ended
up with version "0.13" that works fine for me

I send you my modifications so that you can apply my changes to a future version of xclip if
you find them useful as well. (Even if you don't agree to add the -r option, I kindly ask you
to have a look at the patch because I did some other minor improvements (typos and "-s" as
shortcut for -selection) as well.

I started with the current trunk SVN revision 84 and did the following to create the patch:

philipp@rigel:/projekte/xclip$ svn up
Revision 84.
philipp@rigel:/projekte/xclip$ svn info
Pfad: .
URL: https://xclip.svn.sourceforge.net/svnroot/xclip/trunk
Basis des Projektarchivs: https://xclip.svn.sourceforge.net/svnroot/xclip
UUID des Projektarchivs: 02e78263-a932-0410-9e92-fa172c0799ba
Revision: 84
Knotentyp: Verzeichnis
Plan: normal
Letzter Autor: astrand
Letzte geänderte Rev: 84
Letztes Änderungsdatum: 2010-10-17 18:53:38 +0200 (Son, 17. Okt 2010)

philipp@rigel:~/projekte/xclip$ svn diff > suggestion.patch

Thank you,
Philipp

Reported by: csaa4871

Original Ticket: xclip/patches/5

Hello,

Many times, I end up with random error messages in my terminal like:

Error : target STRING not available

Turns out that xclip is causing those. So first off, these error messages should be prefixed with something like xclip:: so that the users know what's causing those.. below would be so much better:

xclip:: Error : target STRING not available

Can that error be fixed. The simple workaround I need to use each time that happens is echo foo | xclip -i. I wish one didn't need to do that.

We can see how confusing this error is based on following Google search results:

• dnschneid/crouton#1765
• dnschneid/crouton#1931
• dnschneid/crouton#1976
• neovim/neovim#2642
• https://groups.google.com/a/chromium.org/forum/#!msg/chromium-os-dev/oCFnx2Mu8yI/6sKH73hiAgAJ

When an xclip-owned selection has enough data to trigger the use of the INCR protocol when transferring, and an application that doesn't implement the INCR protocol requests clipboard data, xclip will enter the XCLIB_XCIN_INCR state, and then wait forever for the application to delete the INCR property, which will never happen.

While in that state, SelectionRequest events from other applications are not processed, and so the clipboard data becomes inaccessible: any application that tries to access the selection will freeze, waiting forever for a SelectionNotify event from xclip.

In my case, this bug was triggered by fcitx automatically grabbing the contents of the clipboard and locking up xclip whenever I tried to xclip -i something larger than 1MB, like a big enough screenshot. Killing fcitx let the clipboard work as expected, but I don't think a misbehaving application should be allowed to lock up xclip in the first place.

I'm not sure what the best solution would be for this ; I have an ugly fix here which "solves" the problem by just not caring about state at all and always responding to SelectionNotify events. That works well enough for me, but it is still pretty fragile (what happens if two applications request data at the same time?)...

Ideally, xclip should keep track of every INCR transfer separately so that it can still serve clipboard data while it's waiting for another INCR transfer to complete, but i'm not familiar enough with the code to actually implement that.

The configure script tests the installed c compiler with a simple compilation test. It always fails, saying ld cannot find -lXm. The Xm library (along the others) exists in the specified directory (specified by the -L linker option)

configure:2062: gcc -L/usr/X11R6/lib conftest.c -lXm -lXt -lX11 -lXext -lXp -lm -lc >&5
/usr/bin/ld: cannot find -lXm
collect2: ld returned 1 exit status

Reported by: pcarvalhobr2009

Original Ticket: xclip/bugs/1

xclip does not reliably copy/paste large (>1MB) buffers.
Here's a sample transcript.

% dd 'if=/dev/zero' 'bs=2000' 'count=1000' | tr '\000' 'a' | xclip -i 
1000+0 records in
1000+0 records out
2000000 bytes (2.0 MB, 1.9 MiB) copied, 0.0177519 s, 113 MB/s
% xclip -o | wc
      0       1 1048575
% xclip -o | wc
# hangs up - need to manually interrupt it.
^?19708: signal: interrupt
% 
% xclip -o | wc
Error: target STRING not available
      0       0       0
% 

This patch series allows the user to specify the target atom using a new command line option, -target. It includes improved error handling as well as output-only support for certain selection types (ATOM and INTEGER).

Reported by: petercol

Original Ticket: xclip/patches/4

xterm -e xclip && xclip -o

would lead to empty output, and not what the user just typed in in the new terminal.

This is because xclip is not sighup-resistant after forking into background. I put a setsid() syscall just after the fork so xclip is no attached to no terminal and therefore gets no signals.

Reported by: dallaylaen

Original Ticket: xclip/patches/2

Recently updated to Linux Kernel 5.0.0 and found that xclip no longer has the image/png atom available. Running on Arch Linux. Compiled from git with same behavior.

extra/xorgproto 2018.4-1 (260.0 KiB 1.7 MiB) (Installed)
extra/xorg-server-devel 1.20.4-1 (204.6 KiB 1.2 MiB) [xorg] (Installed)
extra/xclip 0.13-2 (14.8 KiB 59.0 KiB) (Installed)
extra/libpng 1.6.36-1 (237.4 KiB 576.0 KiB) (Installed)

/usr/include/X11/Xatom.h exists in filesystem

building xclip-0.11
here's the output of my 'make 2>error.txt':

xclip.c: In function 'doOut':
xclip.c:352: warning: dereferencing type-punned pointer will break strict-aliasing rules

Reported by: *anonymous

Original Ticket: xclip/bugs/2

Hello,
title is pretty explicit. Here's a simple example to reproduce:

>printf abcd | xclip
>xclip -o
>printf 'abcd\n' | xclip
>xclip -o
abcd
>

This is what happens when xclip-copyfile is ran with the --help flag:

$ /usr/bin/xclip-copyfile --help

tar: Usage: dirname NAME\n or: dirname OPTION\nOutput NAME with its last non-slash component and trailing slashes removed;\nif NAME contains no /'s, output `.' (meaning the current directory).\n\n --help display this help and exit\n --version output version information and exit\n\nExamples:\n dirname /usr/bin/ Output "/usr".\n dirname stdio.h Output ".".\n\nReport dirname bugs to [email protected]\nGNU coreutils home page: <http://www.gnu.org/software/coreutils/&gt;\nGeneral help using GNU software: <http://www.gnu.org/gethelp/&gt;\nFor complete documentation, run: info coreutils 'dirname invocation': Cannot chdir: No such file or directory
tar: Error is not recoverable: exiting now

The same thing applies to xclip-cutfile and xclip-pastefile.

Reported by: bapabooiee

Original Ticket: xclip/bugs/5

clears the contents of all clipboards.

Reported by: benkibbey

Original Ticket: xclip/patches/3

Trying to use xclip to paste html into Gmail. Works flawlessly on Linux, doesn't work at all on Mac. No error, so I guess it makes it to X11's clipboard but when trying to paste into the browser nothing happens.

I understand that X11's clipboard and Mac's clipboard are different (which makes sense). Is there any way to cross that barrier? Oh, I am using XA_CLIPBOARD to store the text.

Thank you!

xclip does not appear to be closing stdout. This was noticed to cause compatibility problems when used with newer versions of tmux.

The tmux developer was able to identify this as the cause of an issue originally reported against tmux.

More info: https://sourceforge.net/p/tmux/tickets/40/?limit=10&page=1#9a2b

Reported by: wadetc

Original Ticket: xclip/bugs/9

Dear All, -- I am trying to install xclip on a Mac computer. The configure process fails due to
configure: error: *** X11/Xmu/Atoms.h is missing ***

However such header file exists on /opt/X11/include/X11/Xmu and is not empty. I am issuing
./configure --x-includes=/opt/X11/include/X11/
but I have also tried /opt/X11/include/X11, /opt/X11/include and /opt/X11/; all fail.

I am using the X11 provided by XQuartz (https://www.xquartz.org). I would appreciate any suggestions. Thanks,
Temok

This is a feature request. I have a situation where I would like to make text read from the standard input stream available in two X selections: the primary and the clipboard. Is that possible?

My use case is that I have RHEL 6 running as a guest VM in VMware, and only the primary selection, not the clipboard, seems to be shared with the host, which is running macOS Sierra. So, I want the text to be available in both the primary selection and the clipboard. That way, I can use one short command or alias to copy, and be able to paste from the clipboard within the guest VM and from the primary selection in the host.

For example, I'd like to be able to do something like this in the guest VM:

$ alias pbcopy='xclip -sel primary -sel clipboard'
$ echo 'text to make available in primary and clipboard X selections' | pbcopy

P.S. Thanks for xclip! Great tool!

I use maim to take screenshots and pipe the output to xclip to copy the screenshots to clipboard.

maim --format png /dev/stdout | xclip -sel c -t image/png -i

It works fine somewhere. But I can't paste it to my Virtualbox Windows guest.

Greetings, esteemed masters of the X11 clipboard. I offer a patch to offer half-baked nominal compliance with the end of ICCCM section 2.6.2, which instructs: "selection owners must support conversion to TIMESTAMP, returning the timestamp they used to obtain the selection".

At some point between icaclient_13.0.0.256735_amd64.deb and icaclient_13.1.0.285639_amd64.deb, Citrix Receiver for Linux began demanding that the selection owner respond to queries for the TIMESTAMP target. If a response isn't forthcoming, it refuses to transfer the selection to the Windows box on the other end of its connection. This sort of tedious requirement isn't apparently restricted to this commercial software, as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584686 demonstrates the same behavior with rdesktop, remedied a few years ago. http://lists.freedesktop.org/archives/spice-devel/2014-July/017102.html suggests that some version of VNC might have a similar requirement, so perhaps it isn't even restricted to protocols for accessing Windows remotely.

I started out wanting to paste to Windows from Google Chrome and from various Java applications. Neither of these serve the TIMESTAMP target, Google Chrome seemingly since its switch to the "Aura" toolkit. I plan to raise RFEs on both, but it was xclip that gave me an understanding of what was wrong. It was xclip that gave me a work-around - with the patched version I can leave this running and I'm sorted:

while true; do xclip -o | xclip -i; done &

And I suspect it will be xclip that will be most receptive to my RFE. "But you say it's half-baked". Sadly so. I return CurrentTime for this TIMESTAMP query. This is consistent with what xclip already passes to XSetSelection, with a FIXME about ICCCM compliance. It does enough to rescue me from the icaclient version that I'll need if I'm to upgrade from Debian Wheezy to Debian Jessie. I submit that it's a small step in the right direction.

Reported by: mdorey

Original Ticket: xclip/patches/7

Hi,

I have a problem with xclip not fetching primary clipboard content when certain QT application is running (this application is qtfm, www.qtfm.org\). I suspect this is a xclip problem because pasting primary clipboard inside terminals and such works fine. xclip just grabs the empty string instead of saved text. If I shutdown the QT application, xclip is now able to fetch primary clipboard text without a problem.

For any additional information you need: karabaja4 at gmail.com

Reported by: *anonymous

Original Ticket: xclip/bugs/6

The new utf8 behaviour seems to mangle this specific file in the clipboard unless the -noutf8 switch is used. I'm not sure where specifically things go awry.

The contets of the clipboard is mainly random chinese symbols:
桔獩瀠条⁥慷⁳畡潴慭楴慣汬⁹敧敮慲整⁤牦...

The file itself is mediawiki syntax in ISO-8859-1

Reported by: arand-2

Original Ticket: xclip/bugs/8

I have tried none to build/install it on Msys/Mingw64, but same error when configuring in either Msys or mingw64 window:

...
checking X11/Xmu/Atoms.h usability... no
checking X11/Xmu/Atoms.h presence... no
checking for X11/Xmu/Atoms.h... no
configure: error: *** X11/Xmu/Atoms.h is missing ***

would anyone give me to the definitive guide building one... ?

% xclip -i -sel clip

This just blocks (makes sense)

% printf | xclip -i -sel clip

This returns immediately (makes sense)

% xclip -i -sel clip -verbose
Connected to X server.
Using selection: XA_CLIPBOARD
Using UTF8_STRING.

Blocks here

% printf | xclip -i -sel clip -verbose
Connected to X server.
Using selection: XA_CLIPBOARD
Using UTF8_STRING.
Waiting for selection requests, Control-C to quit
Waiting for selection request number 1

Now I can go to another application, copy text to the clipboard
and xclip will exit as soon as I do the copying. This is very
useful, because it provides an event driven hook for changes to
the X clipboard.

5. printf | xclip -i -sel clip -quiet
   Waiting for selection requests, Control-C to quit
   Waiting for selection request number 1

Behaves the same as 4.

Why is the printf necessary? Why doesn't 3) behave like 4)?

Why is one of -quiet or -verbose necessary? Why doesn't 2) behave like 5)?

% xclip -version
xclip version 0.12
Copyright (C) 2001-2008 Kim Saunders et al.
Distributed under the terms of the GNU GPL

% uname -rs
FreeBSD 10.2-STABLE

The inconsistencies are likely something I'm misunderstanding. Thanks for xclip. It's a nice tool.

Reported by: joeymingrone

Original Ticket: xclip/bugs/10

After installing autoconf and completing the first few steps, the subject is the message I get upon running make inside the xclip directory

The -loops option is broken after merging the pull-request #57.

Reported by @mckellyln.

xclip forks to the background, but it does not daemonize properly (e.g. as explained at http://stackoverflow.com/questions/3095566/linux-daemonize). This bit me while working on https://github.com/kousu/hashapass: if I try to builds script on my script, they hang.

I tracked down the problem to xclip. hang.sh contains a test case showing the problem. When I run it, I see

[kousu@galleon tests]$ ./hang.sh

Before
hang.sh: 455
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:17 0 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:17 1 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:17 2 -> /dev/pts/1
lr-x------ 1 kousu kousu 64 Apr 12 03:17 255 -> /home/kousu/pro/hashapass/tests/hang.sh
lr-x------ 1 kousu kousu 64 Apr 12 03:17 3 -> pipe:[302803]
hang's nested subshell: 456
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:17 0 -> /dev/pts/1
l-wx------ 1 kousu kousu 64 Apr 12 03:17 1 -> pipe:[302803]
lrwx------ 1 kousu kousu 64 Apr 12 03:17 2 -> /dev/pts/1
xclip: 461
total 0
lr-x------ 1 kousu kousu 64 Apr 12 03:17 0 -> pipe:[306902]
l-wx------ 1 kousu kousu 64 Apr 12 03:17 1 -> pipe:[302803]
lrwx------ 1 kousu kousu 64 Apr 12 03:17 2 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:17 3 -> socket:[302804]
^C

with it hanging there until ctrl-c. If you pkill xclip or select something else to copy, the script continues and finishes.

I've played around with this and the culprit is pipe:[302803]: notice that xclip has a write end of it open, because it inherited it from its (now dead) parent which inherited it from the subshell, and the root script has the read end open. Since $(...) blocks until it has all the content, it blocks until all write ends are closed, which never happens because xclip doesn't touch its fds once it forks (or maybe it does, but they aren't going anywhere useful).

I like xclip and use very much--it's in my aliases. I'm happy to be able to contribute to it, if you'll accept my patch.

After the patch, hang.sh no longer hangs:

[kousu@galleon tests]$ PATH=xclip-code/:$PATH ./hang.sh

Before
hang.sh: 523
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:19 0 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:19 1 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:19 2 -> /dev/pts/1
lr-x------ 1 kousu kousu 64 Apr 12 03:19 255 -> /home/kousu/pro/hashapass/tests/hang.sh
lr-x------ 1 kousu kousu 64 Apr 12 03:19 3 -> pipe:[299983]
hang's nested subshell: 526
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:19 0 -> /dev/pts/1
l-wx------ 1 kousu kousu 64 Apr 12 03:19 1 -> pipe:[299983]
lrwx------ 1 kousu kousu 64 Apr 12 03:19 2 -> /dev/pts/1
xclip: 536
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:19 0 -> /dev/null
lrwx------ 1 kousu kousu 64 Apr 12 03:19 1 -> /dev/null
lrwx------ 1 kousu kousu 64 Apr 12 03:19 2 -> /dev/null
lrwx------ 1 kousu kousu 64 Apr 12 03:19 3 -> socket:[304510]

afteR. Z=||
[kousu@galleon tests]$ 

(by the way, your INSTALL instructions are incomplete: they don't mention "autoconf" which is needed before ./configure exists)

Reported by: kousu

Original Ticket: xclip/patches/8

A small suggestion for interaction improvement: xclip should print a short usage information, when invoked with --help. Apart from that, it compiles and works like a charm on my Debian machine.

Reported by: boldewyn

Original Ticket: xclip/feature-requests/1

Hi,
I use xclip for copy/paste from command line, I also use lockwise and bitwarden, they offer clear clipboard after some time.
Can you implement it for xclip such as: --clear-time 10s?
I know some work around like waiting for 10s then copy blank, but it's nice if it's default behavior.

Best regards,
Severus

This is a feature request to
add the text of a parameter or parameters to the clipboard or selection. The text of the parameter itself would be added -- not a file or input identified by it.

xclip forks to the background, but it does not daemonize properly (e.g. as explained at http://stackoverflow.com/questions/3095566/linux-daemonize). This bit me while working on https://github.com/kousu/hashapass: if I try to builds script on my script, they hang.
I tracked down the problem to xclip. hang.sh contains a test case showing the problem. When I run it, I see

[kousu@galleon tests]$ ./hang.sh
Before
hang.sh: 455
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:17 0 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:17 1 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:17 2 -> /dev/pts/1
lr-x------ 1 kousu kousu 64 Apr 12 03:17 255 -> /home/kousu/pro/hashapass/tests/hang.sh
lr-x------ 1 kousu kousu 64 Apr 12 03:17 3 -> pipe:[302803]
hang's nested subshell: 456
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:17 0 -> /dev/pts/1
l-wx------ 1 kousu kousu 64 Apr 12 03:17 1 -> pipe:[302803]
lrwx------ 1 kousu kousu 64 Apr 12 03:17 2 -> /dev/pts/1
xclip: 461
total 0
lr-x------ 1 kousu kousu 64 Apr 12 03:17 0 -> pipe:[306902]
l-wx------ 1 kousu kousu 64 Apr 12 03:17 1 -> pipe:[302803]
lrwx------ 1 kousu kousu 64 Apr 12 03:17 2 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:17 3 -> socket:[302804]
^C

with it hanging there until ctrl-c. If you pkill xclip or select something else to copy, the script continues and finishes.

I've played around with this and the culprit is pipe:[302803]: notice that xclip has a write end of it open, because it inherited it from its (now dead) parent which inherited it from the subshell, and the root script has the read end open.

Since $(...) blocks until it has all the content, it blocks until all write ends are closed, which never happens because xclip doesn't touch its fds once it forks (or maybe it does, but they aren't going anywhere useful).
I like xclip and use very much--it's in my aliases. I'm happy to be able to contribute to it, if you'll accept my patch.
After the patch, hang.sh no longer hangs:

[kousu@galleon tests]$ PATH=xclip-code/:$PATH ./hang.sh
Before
hang.sh: 523
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:19 0 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:19 1 -> /dev/pts/1
lrwx------ 1 kousu kousu 64 Apr 12 03:19 2 -> /dev/pts/1
lr-x------ 1 kousu kousu 64 Apr 12 03:19 255 -> /home/kousu/pro/hashapass/tests/hang.sh
lr-x------ 1 kousu kousu 64 Apr 12 03:19 3 -> pipe:[299983]
hang's nested subshell: 526
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:19 0 -> /dev/pts/1
l-wx------ 1 kousu kousu 64 Apr 12 03:19 1 -> pipe:[299983]
lrwx------ 1 kousu kousu 64 Apr 12 03:19 2 -> /dev/pts/1
xclip: 536
total 0
lrwx------ 1 kousu kousu 64 Apr 12 03:19 0 -> /dev/null
lrwx------ 1 kousu kousu 64 Apr 12 03:19 1 -> /dev/null
lrwx------ 1 kousu kousu 64 Apr 12 03:19 2 -> /dev/null
lrwx------ 1 kousu kousu 64 Apr 12 03:19 3 -> socket:[304510]
afteR. Z=||
[kousu@galleon tests]$ 

(by the way, your INSTALL instructions are incomplete: they don't mention "autoconf" which is needed before ./configure exists)

Reported by: kousu

Original Ticket: xclip/patches/9

Latest Debian uses* wayland* by default, and all programs depending on xclip broke!.

I understand that this is an X utility, but still, if it is trivial to make it work out-of-the-box[*], it would be great.

[*] https://www.geekyhub.in/post/use-xclip-in-gnome-wayland/

Right now, the -t option allows you to select a "target" for whatever you're copying, but what if I wanted to copy more than one thing to more than one target, as browsers do when you copy stuff from a webpage, copying both the HTML to text/html and the unformatted text to text/plain?

Hi!

xclip forks into the background and never exits. This was caused by a commit on July 17th (see below). You can test it like so:

echo "Testing whether xclip exits correctly when the selection is lost."
echo hello | ./xclip -verbose -i >/dev/null 2>&1 &
sleep 1
echo goodbye | ./xclip -i
sleep 1
if ps $! >/dev/null; then 
  echo "FAIL: Zombie xclip yet lives! Killing."
  pkill xclip
else
  echo "PASS: xclip exited correctly after losing selection."
fi

The first xclip process should exit when the second takes the selection, but it does not. I suggest that the above test should be put at the beginning of xctest (before it creates dozens of undying xclip processes).

6623ccd is the first bad commit

In the commit before that, b161f2c, xclip works correctly.

Thanks.

On Ubuntu 16.04.3 LTS I was happily using this alias for several years now: alias clipboard2photo='xclip -selection clipboard -t image/png -o > "`date +%Y-%m-%d_%T`.png"' to paste on terminal an image captured with Ctrl+Shift+PrintScreen,
Somehow now with xclip v0.12+svn84-4 (or maybe a conflict with other updated package) I experience a strange behavior:
Without -verbose the command sometimes generate an image correctly on the upper part of the image and all black in the lower part. No patter found:

• On image 1029px hight only upper 331px (~32%) were right.
• On image 825px hight only upper 296px (~36%) were right.
  other times just:

Error: target image/png not available

With -verbose xclip send not output and sometimes return

Connected to X server.
Using selection: XA_CLIPBOARD
Using image/png.
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  17 (X_GetAtomName)
  Atom id in failed request:  0x0
  Serial number of failed request:  22
  Current serial number in output stream:  22

other times:

Connected to X server.
Using selection: XA_CLIPBOARD
Using image/png.
Type is image/png.

I know the odd sometimes but I couldn't find a pattern. Doesn't seem related to the size of the captured image.

Hi,

First of all, thanks for xclip, it's a very handy tool.

I'd like to report a bug though that prevents me from using it from NodeJS.
Basically, xclip never properly exits. It's been tested on macos and ubuntu.

Xclip version

Well, xclip --version doesn't return anything so I used the command below.

> apt-cache policy xclip
xclip:
  Installed: 0.12+svn84-4build1
  Candidate: 0.12+svn84-4build1
  Version table:
 *** 0.12+svn84-4build1 500
        500 http://fr.archive.ubuntu.com/ubuntu artful/main amd64 Packages
        100 /var/lib/dpkg/status

How to reproduce

echo ok | xclip -sel clipboard
ps -ef | grep xclip

Output:

cyp       1908     1  0 14:31 pts/1    00:00:00 xclip -sel clipboard # <- I did not expect xclip to be still running
cyp       1925  1305  0 14:31 pts/1    00:00:00 grep --color=auto xclip

Original ticket

I first thought this might be a NodeJS issue. You can find the original discussion here.

Thanks for helping!