PSReadLine's Copy/Paste silently fails on KDE Wayland due to hardcoded xclip

[bakamake]

KDE Plasma's Wayland session deliberately uses Wayland-native clipboard protocols (wl-clipboard / wlr-data-control) and does not transparently bridge them back to X11 tools like xclip. This is a design choice, not a bug: KDE wants Wayland sessions to use Wayland toolchains end-to-end.

Meanwhile, PSReadLine's Clipboard.cs hardcodes xclip for Linux:

else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
{
    tool = "xclip";
    args = "-selection clipboard -out"; // / -in
}

All of PSReadLine's system clipboard operations on Linux — the Copy / Cut / Paste bindings shown by Get-PSReadLineKeyHandler (Ctrl+C / Ctrl+x / Ctrl+v / Shift+Insert) — go through this code path. On KDE Wayland, and on any other Wayland-only session where $DISPLAY points at a non-functional XWayland or isn't set at all, xclip either exits non-zero or fails to launch. StartProcess then sets _clipboardSupported to false, and the user is silently dropped to the internal kill ring with a single Ding() — no error, no hint that Wayland is the culprit.

Terminology note: "Yank" in PSReadLine (Ctrl+y) refers to the vi-mode kill ring operation, which is unrelated to the system clipboard. The affected bindings are Copy / Cut / Paste in basic editing mode.

Concrete affected setups:

• KDE Plasma 6 Wayland (the default session since 6.0)
• maybe Sway, Hyprland, river, and other pure Wayland compositors
• GNOME Wayland installs that ship wl-clipboard without xclip

[sharpchen]

I think it'd be better open issue to request a dedicated option to customize the clip command.