Copy (xclip backend) hangs when called in side shell command substitution

[modax]

Hello,

OS: Debian unstable linux-amd64
Pyperclip 1.6.0
Backend in use: xclip
Shell: zsh, dash

pyperclip.copy() hangs when called inside shell's command substitution. When xclip executes, python process is gone while xclip stays up running. But it seems to be Python3-ony problem, Python2 is fine.

$ python3 --version
Python 3.6.4
$  echo "$(python3 -c 'import pyperclip; pyperclip.copy("foo")'; echo "foo")"
<hangs> ...
$ pgrep python
$ pgrep xclip
5659

Python 2.7.14+
$ echo "$(python2 -c 'import pyperclip; pyperclip.copy("foo")'; echo "foo")"
foo
$

[modax]

Well, it seems that xclip is kind of broken in general when used in pipes. E.g. this one hangs as well:

echo "$(echo "foo" | xclip -selection clipboard)"

Could you make xsel preferred over xclip?

[modax]

It seems that stdout must be closed, duped to stderr or piped to /dev/null for xclip work properly. So I worked around this problem with multiprocess:

import multiprocessing
import pyperclip
import os

def pyperclip_copy_wrapper(text):
    # Dup stdout to devnull
    fdnull = os.open(os.devnull, os.O_WRONLY)
    os.dup2(fdnull, 1)
    try:
        pyperclip.copy(text)
    finally:
        os.close(1)
        os.close(fdnull)

def copy_to_clipboard(text):
    p = multiprocessing.Process(name='copy-to-clipboard', target=pyperclip_copy_wrapper, args=(text,))
    p.start()
    p.join()
    return p.exitcode

This works with both xclip and xsel on both Python 2.7 and Python 3.6. Hopefully it does not break anything else.

Btw, xclip version is 0.12+svn84-4+b1

[modax]

Or alternatively, just dup around in the same process. This does not break e.g. gtk clipboard and is probably safe enough:

import os
import pyperclip

def copy_to_clipboard(text):
    stdoutfd_dup = os.dup(1)
    fdnull = os.open(os.devnull, os.O_WRONLY)
    try:
        os.dup2(fdnull, 1)
        pyperclip.copy(text)
    finally:
        # Restore stdout FD and close temporary ones
        os.dup2(stdoutfd_dup, 1)
        os.close(stdoutfd_dup)
        os.close(fdnull)

[chocolateboy]

Well, it seems that xclip is kind of broken in general when used in pipes.

This appears to be the documented behavior of its default -silent (i.e. daemon) mode:

fork into the background to wait for requests, no informational output, errors only (default)

The default action is to silently wait in the background for X selection requests (pastes) until another X application places data in the clipboard, at which point xclip exits silently.

echo "foo" | xclip -selection clipboard | cat
<hangs>

echo "foo" | xclip -selection clipboard -silent | cat
<hangs>

It doesn't hang for me (xclip 0.13 on Linux (Arch)) if it's instructed to work as a filter (i.e. kept in the foreground) via the -f/-filter option e.g.:

echo "foo" | xclip -selection clipboard -f | cat
foo

[FluorineDog]

Installing xsel solves my headache. Maybe make it an explicit dependency better?