Files

T

jochen b1b7e58e4b xclip: the package, and the operator's clipboard from the mesh (hq to-be 42 phase 2.7)

A package and nothing else, the tool the desktop's scripts depend on.
Four Go tools: copy, paste (text, base64 for other types, empty when
nothing), targets and session.

The runtime is given no session words, but runs as the account in the
machine's own namespace, so the session is found rather than configured:
the process's DISPLAY, else the account's processes' DISPLAY and XAUTHORITY
from /proc (the window manager's first), else the only X socket with
~/.Xauthority. Measured with both variables unset: :1 found through i3, the
server answered. With no session every tool says so and runs nothing.

2026-10-04 13:02:23 +02:00

3.2 KiB

Raw Blame History

xclip

The command-line X clipboard, as a module (novox/hq research 026/04: "xclip is a module of its own, a package and nothing else. It is the tool scripts depend on, and a module that needs it requires it"; to-be 42 phase 2 step 7).

Owns

what	where
`xclip`	package `xclip` (official repositories)

Nothing else. The clipboard's history is the clipboard manager's (node-clipboard, a later module). This one is the plain clipboard, without a manager.

Improves

A declared dependency. The window manager's screenshot script copies through xclip on both workstations, and nothing said it needed it. A module that ships such a script requires this one.
The clipboard from the mesh. Text can be put on the operator's clipboard from any machine, for example a command or a link prepared elsewhere, and read back. That is safe with a clipboard manager too: the manager takes what xclip offers into its history.

Reaching the operator's session

The node's tool runtime is a system service running as the operator account. It is given no session words: no DISPLAY, no XAUTHORITY. Measured on both workstations on 2026-10-04:

the runtime runs as the account, in the machine's own mount namespace, with no private /tmp;
the X server's socket is /tmp/.X11-unix/X1;
the cookie is in ~/.Xauthority, readable by the account;
the window manager's environment names both.

So a child of the runtime can reach the session. session.go finds it in this order:

the process's own DISPLAY;
else the DISPLAY and XAUTHORITY of the account's running processes, read from /proc/<pid>/environ (the window manager's by preference), whose socket exists;
else the only X socket, with ~/.Xauthority.

Checked from a shell with both variables unset: it found :1 through the window manager's process, and the server answered. With no session (nobody logged in to the desktop), every tool answers that no graphical session of the account is running, and runs nothing. A server that refuses the cookie is named with the display and how it was found.

What it does not cover. A Wayland session: there wl-clipboard is the tool, and a Wayland module carries it (research 026/04). Also, a copy is held by xclip's own background process, a child of the tool bundle. If the runtime restarts the bundle before another program takes the selection, the copied text is gone.

Tools

All answer JSON. (r) reads; (d) acts in the operator's session.

tool	what
`xclip_copy` (d)	put text (at most 1 MiB) on the clipboard, primary or secondary selection, as a given type (default UTF-8 text)
`xclip_paste` (r)	what a selection holds: text, or base64 for a type that is not text; `empty` when there is nothing; cut at 256 KiB
`xclip_targets` (r)	the types a selection is offered as, without reading it
`xclip_session` (r)	the session the tools reach and how it was found, or why there is none, and whether the server answers

What changes when it is assigned

Nothing on disk on either workstation: xclip is installed explicitly on both.

Leaves as found

The scripts that call xclip (the window manager's screenshot script), which are their own modules'.

3.2 KiB Raw Blame History