[Enhancement] Add binary support

[ParticleMon]

Everything I've found about X clipboard manipulation concerns text. This is sufficient the vast majority of the time. The remaining concerns binary data.

I would like options to 1. get/save/back up clipboard data raw (so it can be assigned to a shell script variable, or, if absolutely necessary, redirect it to a tmp file), and 2. restore a saved clipboard.

Approaches to this might touch on other submitted issues or enhancements, such as:

• Manipulating other buffers (to avoid stripping the clipboard of text formatting and/or binary data?).
• Copying to different targets (such as application/octet-stream when it's not available?).

For my use case, xclip does not seem to offer anything over xsel, and the other xclip tools work only with files and not the clipboard. Or am I missing something?

[mwatts15]

There are some similar features, but binary data is exactly what I use xclip for. For example, I have a script for screen grabs like this:

#!/bin/bash
tempdir="$(mktemp -d)"
fname=$tempdir/chip.png
scrot -s "$fname"
xclip -selection clipboard -t image/png "$fname"
rm -rf $tempdir

the -t is essential. application/octet-stream works.

[hackerb9]

@particlemon, mwatts is correct. Xclip handles binary data whereas xsel does not. xsel considers a null byte the end of input and cannot specify a target.

The default target for xclip is UTF8_STRING, but you can use any type you like. Try copying an object with your web browser and then using xclip -t TARGETS to see what targets are available. (Note that many of the formats are generated only upon request.)

[hackerb9]

Closing as this is not a bug, but feel free to respond if there is still confusion. Perhaps the documentation needs to be improved.

[ParticleMon]

Correct, this isn't about a bug but an enhancement (hence the label ;), even if it were only in documention. (I, too, do not like man pages without examples, so thank you there, too.)

Clearly, I was insufficiently clear: application/octet-stream is not available and does not appear to be generated upon request as expected.

1. Copy any text, graphics, or a combination thereof in a browser, word processor, or other program.

2. xclip -t TARGETS output is silent and waits or hangs, whereas with -verbose it outputs this and waits or hangs: Connected to X server. Using TARGETS.

3. xclip -selection clipboard -t application/octet-stream -o /tmp/xclip.tmp throws this: Error: target application/octet-stream not available

[hackerb9]

Thank you for the clarification. In step two, old versions of xclip required an additional option to signify output:

xclip -o -t TARGETS

[ParticleMon]

To output targets, -o is also required in 0.13, the latest release, which is considered an old version? Do you recommend compiling the current master instead of using the latest release?

But my concern is step 3, not step 2.

[hackerb9]

Hopefully a new version will be released soon as there are many fixes and improvements pending. If you're used to compiling, go ahead, otherwise, just upgrade when the next stable release is out.

While I could see some value in xclip being able to pick a default target and output it, if it was possible to do so, I do not believe X has a way of identifying which of the targets is the "best", "original", "default", or any other way superior. (But I would love to be proven wrong.)

How exactly do you imagine "generating" an octet stream? Xclip could just guess and grab the first one listed, but that's not always going to be what you want. For example, I did a copy of an image in a web browser and it has these targets available:

$ xclip -T
TIMESTAMP
TARGETS
MULTIPLE
text/html
text/_moz_htmlinfo
text/_moz_htmlcontext
image/png
image/bmp
image/x-bmp
image/x-MS-bmp
image/x-icon
image/x-ico
image/x-win-bitmap
image/vnd.microsoft.icon
application/ico
image/ico
image/icon
text/ico
image/jpeg
image/tiff

The first real target is "text/html" which includes the HTML used to render the image, including the filename, src URL, alt text, and geometry.

Note that there are also multiple image targets offered by the selection owner (Mozilla Firefox). Only one of them is the original format that was copied, all the rest are generated on the fly by Firefox. Xclip knows nothing about data formats and never generates them.

[ParticleMon]

Your question is better suited for one nearer your pay grade. I can only provide a vision of functionality I perceive as desirable yet presently absent, not likely to propose how to implement it. So, please excuse my ignorance.

It seems that reliance on available targets may by the crux of the issue. Is this imposed by X? Is there not a raw clipboard with the "original" data, without the fanning out into multiple MIME types? To retain the raw clipboard, could it not be either cast to or entirely encapsulated in an octet stream?

[hackerb9]

We are all ignorant, if not in one way then in another, so no need to apologize.

X provides for not only multiple clipboards ("selections") but multiple data formats ("targets") on each clipboard. When a program "takes ownership of the selection" (that is, does a copy), it advertises what targets (data formats) it is willing to answer to. That much is required by X. The problem is what X does not impose, nor even suggest, is a way for the client to mark one of the targets as preferred. As far as I know, anyhow. Here's the documentation I've been working from:

https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#peer_to_peer_communication_by_means_of_selections

If you read up on the ICCCM, you'll eventually reach my pay grade, which is volunteer, working for kind words. On the other hand, beware that some have reported the ICCCM is not just a "bad" specification, but genuinely evil and capable of raising eldritch horrors from the deep. So, there's that.