xclip icon indicating copy to clipboard operation
xclip copied to clipboard

option to --inspect if selections are not empty

Open techtonik opened this issue 7 years ago • 10 comments

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)

techtonik avatar Sep 25 '18 10:09 techtonik

This is needed, because there are not reliable tools to check clipboard contents. People report that xclip can miss data in clipboard https://askubuntu.com/questions/705620/xclip-vs-xsel/1078667#comment1772076_1078667

techtonik avatar Sep 28 '18 09:09 techtonik

Your example of --inspect is interesting, but misses one of the aspects of X selections: not only are there three different places to cut and paste to, but each of them can contain multiple datatypes. For example, try right clicking on an image in a web browser and doing "Copy Image". Then run this from the command line:

$ xclip -selection clipboard -t TARGETS

You'll see that the clipboard selection actually mentions various mimetypes that the image can be pasted as. For example,

TIMESTAMP
TARGETS
MULTIPLE
SAVE_TARGETS
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

Notice that you can even paste it as "text/html" which would give you the link like so:

<img class="avatar" src="https://avatars2.githubusercontent.com/u/10174223?s=80&amp;v=4" alt="@hackerb9" width="40" height="40">

Furthermore, that data may not exist until you paste it! When you paste a selection in X, the data can be generated on the fly by the application that did the cut. For example, it might convert an image from jpeg to png only once an application tries to paste the image/png target.

$ xclip -o -t image/png | file -
/dev/stdin: PNG image data, 80 x 80, 8-bit/color RGBA, non-interlaced

hackerb9 avatar Oct 12 '19 10:10 hackerb9

Who assigns those mimetypes?

Is it be possible to give all the details like this?

$ xclip --inspect
PRIMARY: empty
SECONDARY: 209 bytes
- TIMESTAMP
- TARGETS
- MULTIPLE
- SAVE_TARGETS
- 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
CLIPBOARD: dynamic

techtonik avatar Nov 25 '19 12:11 techtonik

The mime-types are announced by the program that holds the selection. That program can name the targets any arbitrary string, but MIME is standard.

I think some of your example is possible. For example, if xclip -t TARGETS returns "not available", then you could say the selection is "empty". Also, listing the MIME types available is possible, as you saw in my previous message.

But I'm not sure that that makes sense to show the number of bytes in a selection. Different targets would have different counts. Even if you decided you wanted to only count strings, would you count the bytes in STRING or UTF8_STRING.

You might think you could count up the bytes of the "original" target (e.g., image/png) instead of targets created dynamically (image/x-win-bitmap, application/ico, etc), but I believe X doesn't have a way to differentiate.

I suppose you could request all of the targets and count their bytes individually, but that could theoretically put a big load on the original app as it does a bunch of unnecessary conversions. (Imagine someone has copied a video file from a program which can convert it to many other formats).

hackerb9 avatar Dec 04 '19 05:12 hackerb9

For your original problem with screenshots, couldn't you simply check if one of the targets is an image? For example,

#!/bin/bash
while sleep 1; do
    if xclip -selection clipboard -t TARGETS | grep -q image/png; then
	t=$(xclip -selection clipboard -t TIMESTAMP)
	if [[ $t != $oldt ]]; then
	    oldt=$t
	    date
	    echo -n "Bytes: "
	    xclip -selection clipboard -t image/png | wc --bytes
	fi
    fi
done

hackerb9 avatar Dec 04 '19 05:12 hackerb9

Pull request #88 should close this issue as it gives tab completion (for GNU Bash) which makes for easy inspection of selections. For example, one could type xclip -t and then press the TAB key twice to see a list of all data types offered by the selection owner.

hackerb9 avatar Nov 05 '20 05:11 hackerb9

I think some of your example is possible. For example, if xclip -t TARGETS returns "not available", then you could say the selection is "empty". Also, listing the MIME types available is possible, as you saw in my previous message.

What if somebody names their clipboard data as "not available"? Is it possible to distinguish this case from the error output?

techtonik avatar Dec 17 '20 21:12 techtonik

But I'm not sure that that makes sense to show the number of bytes in a selection. Different targets would have different counts. Even if you decided you wanted to only count strings, would you count the bytes in STRING or UTF8_STRING.

I am interested to know raw data size in bytes, for debugging. Everything else doesn't make sense to me. Or you want to say that API for accessing clipboard is typed? So it is not just name as a string and data as raw data which is then parsed by receiving program?

techtonik avatar Dec 17 '20 21:12 techtonik

This didn't work. Just hung.

$ xclip -selection clipboard -t TARGETS

This showed the list of possible targets.

$ xclip -selection clipboard -t TARGETS -o

I see no option to clear clipboard with xclip, so I can't say what is the TARGETS output when the clipboard is empty.

techtonik avatar Dec 17 '20 21:12 techtonik

For your original problem with screenshots, couldn't you simply check if one of the targets is an image? For example,

That may work, but for debugging it needs to check all clipboards I have. That's why I am pushing for -inspect.

techtonik avatar Dec 17 '20 21:12 techtonik