gitui-org/gitui · error · anyhow::Error

`{command:?}`: {msg}

Error message

`{command:?}`: {msg}

What it means

The clipboard provider spawned successfully, ran to completion, but exited with a non-zero status. gitui formats the child's captured stderr (when pipe_stderr was enabled and stderr is non-empty) or the bare ExitStatus into the message, so the provider's own diagnosis - typically xclip's 'Error: Can't open display' or wl-copy's compositor complaints - is visible inside the braces.

Source

Thrown at src/clipboard.rs:48

		.stdin
		.as_mut()
		.ok_or_else(|| anyhow!("`{command:?}`"))?
		.write_all(text.as_bytes())
		.map_err(|e| anyhow!("`{command:?}`: {e:?}"))?;

	let out = process
		.wait_with_output()
		.map_err(|e| anyhow!("`{command:?}`: {e:?}"))?;

	if out.status.success() {
		Ok(())
	} else {
		let msg = if out.stderr.is_empty() {
			format!("{}", out.status).into()
		} else {
			String::from_utf8_lossy(&out.stderr)
		};
		Err(anyhow!("`{command:?}`: {msg}"))
	}
}

// Implementation taken from https://crates.io/crates/wsl.
// Using /proc/sys/kernel/osrelease as an authoritative source
// based on this comment: https://github.com/microsoft/WSL/issues/423#issuecomment-221627364
#[cfg(all(target_family = "unix", not(target_os = "macos")))]
fn is_wsl() -> bool {
	if let Ok(b) = std::fs::read("/proc/sys/kernel/osrelease") {
		if let Ok(s) = std::str::from_utf8(&b) {
			let a = s.to_ascii_lowercase();
			return a.contains("microsoft") || a.contains("wsl");
		}
	}
	false
}

// Copy text using escape sequence Ps = 5 2.

View on GitHub (pinned to 2fa693cb6e)

Solutions

  1. Run the exact command shown in the error message by hand (echo hi | <command>) and read its stderr - it states the root cause.
  2. Fix the environment it complains about: export DISPLAY=:0, restart the compositor, re-enable WSL interop, install termux-api.
  3. Switch to the provider matching your session (wl-clipboard on Wayland) or run gitui inside the graphical session.
  4. For ssh-only workflows, use a terminal supporting OSC 52 clipboard escapes so gitui can copy without a local socket.

Example fix

# error shows the tool's own stderr, e.g.
# `"xclip -selection clipboard": Error: Can't open display: :1. (null)`
# before
ssh host gitui            # copy fails inside popup
# after: forward X and ensure the remote has a provider
ssh -X host
sudo apt install xclip && gitui
Defensive patterns

Strategy: validation

Validate before calling

# validate the full path - spawn AND exit status - in the session gitui will use
printf ok | xclip -selection clipboard && echo 'X11 clipboard works'
printf ok | wl-copy && echo 'wayland clipboard works'
[ -n "$DISPLAY${WAYLAND_DISPLAY:-}" ] || echo 'no display env: providers will fail'

Try / catch

match copy(text) {
    Err(e) => { show_msg(format!("clipboard: {e}")); Ok(()) } // message embeds provider stderr
    r => r,
}

Prevention

When it happens

Trigger: xclip running with DISPLAY unset or pointing at a dead server; wl-copy with no compositor listening on the Wayland socket; termux-clipboard-set without the termux-api app side installed; clip.exe under WSL with Windows interop disabled by hardening.

Common situations: Copying over ssh after the remote display session died; headless hosts reached from a terminal that does not support OSC 52; WSL images hardened with interop removed; Termux without termux-api.

Related errors

AI-assisted analysis of gitui-org/gitui@2fa693cb6e (2026-08-16). Data as JSON: /api/errors/ea8ec6823ec57a9d. Report an issue: GitHub.