SUMMARY When an application is launched from a hotkey in Wayland (havent tested X11), it doesnt have stdin, stdout, stderr attached which can result in problems when these applications try to use them for e.g. logging. This problem was noticed when using wl-clipboard which works when running it from a script, but doesnt when running from a shortcut (e.g. as part of a script) STEPS TO REPRODUCE with wl-clipboard 1. Write script which uses wl-copy (e.g. wl-copy "foobar") 2. Add script as shortcut 3. Launch Keybind (press it!) 4. Check clipboard content GENERAL STEPS TO REPRODUCE 1. Write script to test for stdin/stdout/stderr # Test for stdout if [ -t 1 ]; then echo "stdout exists" >> /tmp/output else echo "stdout does not exist" > /tmp/output fi 2. Launch directly and check /tmp/output stdout exists 3. Launch via shortcut / keybind and check /tmp/output stdout does not exist EXPECTED RESULT The standard streams should be connected e.g. stdout & stderr to system journal or at least /dev/null SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.27.4 (available in About System) KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Graphics Platform: Wayland ADDITIONAL INFORMATION I assume this problem also exists in X11, but havent tested it. RELATED https://bugs.kde.org/show_bug.cgi?id=469238
Issue for wl-clipboard where this has been discovered: https://github.com/bugaevc/wl-clipboard/issues/153
> 2. Add script as shortcut Where specifically are you doing this?
(In reply to Nate Graham from comment #2) > > 2. Add script as shortcut > Where specifically are you doing this? Settings > Shortcuts > Add Application/Command (I know both do the same in the end, but have tested both, issue exists with both)
I have discovered this issue directly from the linked wl-clipboard issue ( https://github.com/bugaevc/wl-clipboard/issues/153 ) while creating one of my own ( https://github.com/bugaevc/wl-clipboard/issues/201 ). Lack of stdout/stderr redirection for scripts triggered by KDE hotkeys seems like a weird design choice. I expected possible errors to be automatically redirected to DE's logs like what I observed in Sway before. I can provide more complete setup reproducing the issue: in `plasma-manager-commands.desktop`: > [Desktop Action get-kwallet-password] > Exec=get-kwallet-password > Name=Copy KWallet Password to clipboard in `~/.config/kglobalshortcutsrc`: > [plasma-manager-commands.desktop] > _k_friendly_name=Plasma (Home) Manager Commands > foot=Meta+Return,none,foot > get-kwallet-password=Meta+Shift+P\tMeta+J,none,get-kwallet-password in `~/.local/bin/get-kwallet-password`: > #!/usr/bin/env bash > pass show kwallet | wl-copy -n > notify-send --expire-time=10000 --wait "KWallet password" "is available in clipboard until this notificaton closes" > for i in {1..10} ; do > echo "password cleared $i times" | wl-copy > done > wl-copy --clear
I just upgraded to Fedora 39 from Fedora 38. In the process, I upgraded to KDE 5.27.9 . I hit this bug on upgrade. I have (something like) this line in a script I fire off via keyboard shortcut: printf "${thing}" | wl-copy I was able to work around this bug by ensuring that output and error were hooked up to something inside the script: printf "${thing}" | wl-copy >/dev/null 2>/dev/null This works because the pipe supplies stdin, the `>` supplies stdout, and the `2>` supplies a stderr for the wl-copy process.
>1. Write script to test for stdin/stdout/stderr # Test for stdout if [ -t 1 ]; then echo "stdout exists" >> /tmp/output else echo "stdout does not exist" > /tmp/output fi Are you sure this is a useful test? -t means "file descriptor FD is opened on a terminal". But we are not launching things in a terminal, so I wouldn't expect it to be true? Or am I misunderstanding this?
Using wl-copy in a script launched from a shortcut works as expected for me on Plasma 6 (but not Plasma 5). I suspect https://invent.kde.org/plasma/kglobalacceld/-/commit/d9607ef5d150135937f9467c9ce27fa9ba8cbabe has fixed it, but I can't say with certainty