Perhaps some background would help here; I start by highlighting this
section in "man xclip":
-l, -loops
number of X selection requests (pastes into X applications)
to wait for before exiting, with a value of 0 (default) causing xclip to
wait for an unlimited number of requests until another application
(possibly another invocation of xclip) takes ownership of the selection
What's mentioned here as "the selection" is approximately what you probably
think of as "the clipboard".
X-windows does not itself hold the clipboard. Instead, that responsibility
falls to the program offering the copy. When a program goes "copy", it
notifies the WM that it has a "selection" available; then subsequent
requests for pasting are forwarded to that program, and it replies with the
selection to be pasted. The WM notifies the original program when the
selection is no longer required, in particular, when it has been supplanted
by a notification from another program. If the original program dies or
exits, the clipboard dies with it.
This means that xclip must notify the WM that it has a selection and then
stay active so that a later program can ask for it, but at the same time,
xclip is expected to exit immediately once it's captured its stdin.
It manages to do both simply by forking.
However the new child process thus created does not close its stdin, stdout
or stderr.
The forked child will exit when the WM tells it that its selection is no
longer required, and that's the delay that you're seeing.
On Sat, 18 Nov 2023 at 23:36, dbarrett--- via Bug reports for the GNU
Bourne Again SHell <bug-bash@gnu.org> wrote:
> The following command, when run in bash, should copy the word "foo" to
> the X primary selection (by process substitution), output the line
> "fxx", and exit:
>
> echo foo | tee >(xclip -i) | tr o x
>
> The command does print "fxx" but then it hangs
>
The same command behaves correctly when run in zsh
>
If zsh is not connecting the output of xclip to the input of tr, I would
regard that as INcorrect.
I note that both the follow "hang" the same in zsh and bash:
xclip </dev/null | cat
echo foo | ( tee >(xclip -i) ) | tr o x
... because both wait for the forked child of xclip to finish.
The fact that you don't *want* the output of xclip connected to tr (because
it makes tr wait for xclip *and all its children* to finish, while the
shell waits for tr to finish) does not make zsh "correct".
-Martin
