Error : target STRING not available

[kaushalmodi]

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:

• Error : target STRING not available dnschneid/crouton#1765
• error: target string not available dnschneid/crouton#1931
• Cannot connect to extension, unable to start display - apparently after chrome os update dnschneid/crouton#1976
• Clipboard error : Target STRING not available when running neovim/neovim#2642
• https://groups.google.com/a/chromium.org/forum/#!msg/chromium-os-dev/oCFnx2Mu8yI/6sKH73hiAgAJ

[PovarovDenis]

Same problem. The error appears when system clipboard contains non-string value (file for example). My proposal is to print something like "Binary data" rather an error.

[sgraf812]

I'm unsure if this is related, but when I yank to "+ in vim and suspend with Ctrl+Z, I get the same error. Note that it works if I keep vim open. Resuming vim doesn't help. See https://askubuntu.com/questions/1013724/x11-clipboard-not-available-after-quitting-vim

[sgraf812]

Nevermind, my issues were due to https://wiki.ubuntu.com/ClipboardPersistence.

[hackerb9]

I've merged in @hwangcc23 's fix for this issue which makes the error message more explicit about what the problem is. However, if the "solution" people want is to set the clipboard so any random string as suggested by the original report:

echo foo | xclip -i

then perhaps what is actually needed is for xclip to not be so verbose about errors. It can simply return an error if a target isn't available and not print anything unless -verbose is given.

What do people think?

[hackerb9]

Alternately, we could add an option to make even error messages not be printed out and then ask the neovim project (or whoever it is that is calling xclip) to use that option so logs won't get filled up by needless error messages.

The only problem is I'm not sure what that option would be called. We already used "-silent" to mean show error messages but nothing else and "-quiet" to mean be slightly more verbose than -silent and also run in the foreground. Perhaps those options should be renamed? "-silent" could be called "-background" or "-normal" and "-quiet" could be changed to "-foreground".

[ghost]

I'm not sure how this is relevant, but i've been stumped by a similar issue when using xclip inside Emacs' eshell shell interpreter. E.g.:

1. M-x eshell
2. $SHELL -c 'echo foo | xclip -i'
3. xclip -o

Errors out with 'Error: target STRING not available'

While if i do:

1. M-x term
2. $SHELL -c 'echo foo | xclip -i'
3. xclip -o

I get foo back.

Is this relevant to this issue?

[krishenm94]

Any progress on this? getting a related issue with nvim.

neovim/neovim#15478

[hackerb9]

I'm not sure how this is relevant, but i've been stumped by a similar issue when using xclip inside Emacs' eshell shell interpreter.

@polezaivsani Your issue is relevant in that it appears the "error" is that xclip is reporting an error.

I asked what people thought about this almost a year ago:

I believe what is actually needed is for xclip to not be so verbose about errors. It can simply return an error if a target isn't available and not print anything unless -verbose is given.

I didn't get any response, which I suppose is appropriate as that seems to be the correct solution: say nothing. 😂

@astrand I propose the following when a TARGET is not available:

1. Do not print an error message in simplest case, xclip -o, where we're picking a default TARGET for them.
2. If the user specified a TARGET, then do print an informational message.

I say "informational" instead of "error" message so that we can silence it using command line options. (Xclip has no way to suppress error messages).

Does that sound good?

---

Eventually, we should clean up the -silent and -quiet options, neither of which suppress error messages and are confusingly intertwined with whether xclip daemonizes itself:

1. Add -foreground and -background options that control whether xclip runs in the foreground or background (during -in)
2. Change -silent and -quiet to only affect the verbosity level.
3. Add a new option that also suppress error messages (as in this bug).

[Freed-Wu]

the bug affect neovim/neovim#20862

$ touch a
$ xsel -ib < a
$ xsel -ob
$ xclip -o -selection clipboard
Error: target STRING not available

[ilya-bystrov]

Came here after googling. Probably, could be helpful for someone.

I had the similar issue with my clipboard editor.

xterm -e /bin/bash -c 'xclip -o | vipe | xclip -i -sel p -f | xclip -i -sel c'

Adding -i flag fixed an issue

xterm -e /bin/bash -i -c 'xclip -o | vipe | xclip -i -sel p -f | xclip -i -sel c'

[xgqfrms]

this solution may help

# set $DISPLAY env ✅
$ export DISPLAY=:0.0

# bad usage ❌
$ lsusb | xclip -o >> xclip.md
Error: target STRING not available

# use multi times pipe operators 🚀
# right usage ✅ （copy fisrt，the paste）
$ lsusb | xclip -i | xclip -o >> xclip.md