Xclip does not change the clipboard content

xclip

I'm trying to give the following command:

echo "hi" | xclip -selection c

This doesn't work? It has worked in the past, but never consistently. I also tried

echo "hi" | xclip -selection primary

echo "hi" | xclip -selection clipboard

etc….

xclip is installed (I'm pretty familiar with Linux 🙂 ) and there is no output, it just moves onto the next line and my clipboard contents do not change.

Here is my linux version:

[1450] cgeorge@uaf-7 $ cat /proc/version
Linux version 2.6.18-371.1.2.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Tue Oct 22 12:51:53 EDT 2013

Best Answer

X doesn't really have a "clipboard" by default. Selections are managed by the application that "owns" them, and if you want to copy or paste a selection, this is done by communication between both applications, which means the other application that holds the selection must still be running.

There is however a method to take over a selection, so there are generic clipboard applications like xclipboard, which allow other applications to "send" a XA_CLIPBOARD selection.

So, (1) either run xclip with option -l so it keeps running until a second application pastes successfully (that can require several communication rounds, so -l 1 can fail), or (2) run a clipboard manager, and use -selection XA_CLIPBOARD.

You also said "you're clipboard contents don't change", but it's not really clear which "clipboard" you mean, and how the checked that.

Related Solutions

Tmux Clipboard – How to Copy a Buffer to the Clipboard

Here documents need newlines. For example, in a shell script, you can write

cat <<EOF >somefile; echo  done
file contents
EOF

I don't think tmux lets you put newlines there, and even if it did, this wouldn't be a good approach. What if the data itself contains HERE alone on a line (e.g. because you're copying your .tmux.conf)?

I suggest to write the buffer contents to a temporary file. Untested:

bind-key p save-buffer ~/.tmux-buffer \; run-shell "xsel -i -b <~/.tmux-buffer && rm ~/.tmux-buffer"

There's a race condition if you use this command in two separate tmux instances. I don't know how to solve this.

Abbreviated long options on the command line of xclip

xclip uses the X Toolkit library, which does the options-parsing. All of the options can be abbreviated. The library only gives an error if there is an ambiguity.

Options, of course, are things like -select which can be abbreviated as -sel (possibly even -s).

xterm uses the same library, same behavior. It uses special cases (outside the library) to make the -v command a unique abbreviation for -version, etc.

X Toolkit uses a single dash - for options, and does not distinguish between "short" and "long" because it is not an extension of getopt. As I pointed out in Single dashes - for single-character options, but double dashes -- for words?, it was introduced around the same time as GNU getopt, which did extend getopt. This was before POSIX came along, but AT&T getopt had several years of use, establishing its role for single-character options. GNU getopt uses a double-dash -- to denote long options.

Noting a long digression, you can read the source code for GNU getopt (which is unrelated to xclip) from its git repository, e.g.,

 369    Long-named options begin with `--' instead of `-'.
 370    Their names may be abbreviated as long as the abbreviation is unique
 371    or is an exact match for some defined option.  If they have an
 372    argument, it follows the option name in the same ARGV-element, separated
 373    from the option name by a `=', or else the in next ARGV-element.
 374    When `getopt' finds a long-named option, it returns 0 if that option's
 375    `flag' field is nonzero, the value of the option's `val' field
 376    if the `flag' field is zero.

Best Answer

Related Solutions

Tmux Clipboard – How to Copy a Buffer to the Clipboard

Abbreviated long options on the command line of xclip

Related Question