| Summary: | Service file specifiying 'Run in terminal' gives "Error code 100, Could not find the program ‘konsole’" after Plasma 5.18.5 update. | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | lnxusr |
| Component: | general | Assignee: | Jonathan Marten <jjm> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 574873786, alex.kdebugzilla, bugseforuns, david.cortes.rivera, dev, faure, gratzer, jjm, kde, kde, kdelibs-bugs, lvqp, nate, rcburness, robyfary, samoht0-bugzilla, stanczakdominik, tagwerk19, tsadler, web |
| Priority: | VHI | Keywords: | regression |
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kio/6452a34cf01d03d3167b38bc28a2fe8e13569021 | Version Fixed In: | 5.71 |
| Sentry Crash Report: | |||
|
Description
lnxusr
2020-05-11 21:13:56 UTC
*** Bug 421378 has been marked as a duplicate of this bug. *** I'm getting this on master with CommandLauncherJob, too. @dfaure: Could this be a regression in KRun/KProcessRuner? (with ApplicationLauncherJob, obviously) I'm experiencing this, too. My use case is that I have a .desktop launcher that contains Terminal=true And I receive that same error. I can confirm this bug on Arch Linux when I try to launch htop via kickoff. Possibly related to Bug 421364 same problem here, in KDE Neon after upgrade 5.18.5 (Copied from duplicate bug 421454) SUMMARY The desktop file: [Desktop Entry] Exec=ls Name=Terminal test Terminal=true TerminalOptions=--hold Type=Application should launch the default terminal application and execute the command. However, as reported on bug #421364, if the desktop file is launched with 'kioclient5 exec test.desktop' or by any other means an error box is shown: Unknown error code 100 Could not find the program 'konsole' Please send a full bug report at https://bugs.kde.org. with the debug message: kioclient(1227906) findNonExecutableProgram: Internal program error. QStandardPaths::findExecutable couldn't find "konsole" but our own logic found it at "/usr/bin/konsole" . Please report a bug at https://bugs.kde.org The problem seems to be in KIO::DesktopExecParser::resultingArguments() where, if service.terminal() is true, the user's configured terminal application or konsole as a default is prepended to the command line (with appropriate options). However, this is most likely to be a relative path. This then triggers the "nonExecutable" check in KProcessRunner::KProcessRunner(). STEPS TO REPRODUCE 1. Execute the desktop file as above using kioclient5. OBSERVED RESULT Error and debug messages as above are shown, and no terminal is launched EXPECTED RESULT A terminal is launched and the current directory is listed SOFTWARE/OS VERSIONS KDE Frameworks Version: 5.71.0 Qt Version: 5.14.2 *** Bug 421454 has been marked as a duplicate of this bug. *** *** Bug 421479 has been marked as a duplicate of this bug. *** Thanks for submitting a patch! So, we have to make some changes or to wait for KDE update? Git commit 6452a34cf01d03d3167b38bc28a2fe8e13569021 by Jonathan Marten. Committed on 14/05/2020 at 18:17. Pushed by marten into branch 'master'. Fix service file specifying 'Run in terminal' giving an error code 100 Happens because KIO::DesktopExecParser::resultingArguments() prepends the terminal application to the command line. If this is a relative path, as it is most likely to be (and will be in the default 'konsole' case), the "realExecutable" check in KProcessRunner::KProcessRunner() is triggered and the job aborts with an error. Expand the specified terminal executable into a full path in resultingArguments(), and return an error immediately if it cannot be found. This full terminal path is not relative for the KProcessRunner::KProcessRunner() check and does not fail. Check that resultingArguments() is not empty (an error return) before accessing the first word of the command, so that it does not assert if the list is empty. Also only call resultingArguments() once. FIXED-IN: 5.71 Differential Revision: https://phabricator.kde.org/D29738 M +9 -1 src/core/desktopexecparser.cpp M +9 -8 src/gui/kprocessrunner.cpp https://commits.kde.org/kio/6452a34cf01d03d3167b38bc28a2fe8e13569021 Thank you, but I don't understand yet what I should do (if I should do anything). Wait for KDE Frameworks 5.71 to be released and then upgrade to it. Can this fix be applied to kio 5.70? 5.70 was already released and Frameworks do not have bugfix releases. It's up to distro packagers to backport the fix at this point, if they don't want their users to have to wait a month. In case this is helpful (and not inappropriate to share here)... Temporary workaround that works for my situation (.desktop file): Exec=/usr/bin/konsole -e "[path to script]/hello.sh" (In reply to ryantg from comment #19) > In case this is helpful (and not inappropriate to share here)... > > Temporary workaround that works for my situation (.desktop file): > > Exec=/usr/bin/konsole -e "[path to script]/hello.sh" Besides to apply the proposed Exec change, if your desktop file contains Terminal=true remember to change it to false Terminal=false *** Bug 421587 has been marked as a duplicate of this bug. *** *** Bug 421991 has been marked as a duplicate of this bug. *** *** Bug 422270 has been marked as a duplicate of this bug. *** (In reply to sahsanu from comment #20) > (In reply to ryantg from comment #19) > > In case this is helpful (and not inappropriate to share here)... > > > > Temporary workaround that works for my situation (.desktop file): > > > > Exec=/usr/bin/konsole -e "[path to script]/hello.sh" > > Besides to apply the proposed Exec change, if your desktop file contains > Terminal=true remember to change it to false Terminal=false I need to keep "on hold" the konsole, otherwise it closes too fast. I use : Exec=/usr/bin/konsole --hold -e "[path to script]/hello.sh" Just upgraded to the latest 5.19 and the bug is still there :-| When is it going to get pushed to the users? on next Saturday https://community.kde.org/Schedules/Frameworks *** Bug 422821 has been marked as a duplicate of this bug. *** *** Bug 423207 has been marked as a duplicate of this bug. *** |