clipboardy

After taking ownership of the clipboard, forks and keeps serving the clipboard contents in the background until another app takes over. The background process inherits our stdio, so piping its output made us wait for a process that only exits when something else is copied. Pass a real file descriptor for stderr instead. The background process can hold it open indefinitely without blocking us, and we can still read back what it wrote, so the X11 fallback heuristic and error messages are preserved. Note that execa's own redirection does not work here, as it is implemented as a pipe. Also ignore stdout, since wl-clipboard before 2.1 does not redirect it before forking. Fixes #111

Hi, there's some odd behavior with wayland (PopOS 24.04 LTS, Cosmic DE, Wayland) where the promise doesn't resolve and blocks the execution until something else copies something to the clipboard. Steps to reproduce: Pre-requisites Use linux distro with wayland (in my case PopOS with Cosmic Desktop Environment, that uses Wayland by default) Use Node (no browsers) 1. Simple script 2. Run it, it blocks in wayland (wl-copy) 3. Copy something to the clipboard, it will stop blocking the execution and print the rest: I think it could be related to Wayland's clipboard ownership model, where wl-copy remains running while it owns the clipboard. It looks like clipboard.write() waits for the wl-copy process to exit, so the returned promise doesn't resolve until another application takes ownership of the clipboard. When you run in the terminal it doesn't happen because it creates a fork process in the background and redirects its descriptors but, when using execa within node and executing I think that maybe the child process of Node could be keeping STDERR/STDOUT open and then the await never resolves until something else takes the ownership of the clipboard and wl-copy process gets killed. Also, I didn't tested it but should be blocking the entire main thread for the same reason. Expected behaviour I would expect to resolve once the clipboard contents have been successfully handed off to wl-copy, rather than waiting for the lifetime of the wl-copy process.

I'm using the Clipboard Ring extension (https://github.com/SrTobi/code-clip-ring) in VS Code, which has a dependency on clipboardy ^1.2.3. I occasionally get the following error, preventing me from pasting the content of my clipboard: RUST_BACKTRACE=1 Seems strange that clipboard_x86_64.exe reports an Error with what looks like a success message? I think restarting VS Code might fix this, but it's a nuisance. Any ideas? Other info: I'm running Windows 10 Home N. VS Code: Version 1.24.1. IssueHunt Summary sindresorhus has been rewarded. Backers (Total: $60.00) issuehunt ($60.00) Submitted pull Requests #835 Add and to hook state Tips Checkout the Issuehunt explorer to discover more funded issues. Need some help from other developers? Add your repositories on IssueHunt to raise funds.