Bug 415567

Summary:	"Could not find the program" dialog when program is found but malformed
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	Alex <agrambot>
Component:	general	Assignee:	David Faure <faure>
Status:	CONFIRMED ---
Severity:	minor	CC:	a.samirh78, kdelibs-bugs, nate, samoht0-bugzilla
Priority:	NOR
Version:	5.65.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Alex 2019-12-25 23:52:32 UTC

SUMMARY
I discovered this when one of my programs that I have a shortcut to in Kickoff needed to be rebuilt to link with a new version of a library. 
Running the executable directly resulted in an error code of 127:

  error while loading shared libraries: libMagickWand-7.Q16HDRI.so.6: cannot open shared object file: No such file or directory

When attempting to launch in Kickoff I got a popup with the message "Could not find the program", even though that wasn't the error.

Other variants I tried were to replace the executable with an empty file and to remove the executable bit from the executable.

STEPS TO REPRODUCE
1. Create a shortcut to an executable in Kickoff (or Krunner, etc.)
2. Make the executable somehow throw an error instead of loading. For example, use `sudo chmod -x <file>`.
3. Try to launch the program through the shortcut.

OBSERVED RESULT
"Could not find the program" dialog pops up.

EXPECTED RESULT
A pop up dialog that states the actual reason why the program did not launch.

SOFTWARE VERSIONS
KDE Plasma Version: 5.17.4
KDE Frameworks Version: 5.65.0
Qt Version: 5.14.0

ADDITIONAL INFORMATION
The message is produced in kio/kio/krun.cpp in KProcessRunner::slotProcessExited.

It would be nice if the exact error message/code was passed through to give the user the precise information. Perhaps it could be hidden, but expandable in an "Additional Information" field?

Comment 1 Ahmad Samir 2020-02-07 16:20:11 UTC

https://phabricator.kde.org/D27216

Comment 2 David Faure 2020-04-27 21:22:31 UTC

Git commit 05cbbf06384bae0cad8de19d659864c0f8dbd651 by David Faure.
Committed on 27/04/2020 at 21:22.
Pushed by dfaure into branch 'master'.

Detect executables without +x permission in $PATH to improve error message

Summary:
QStandardPaths::findExecutable will not return to us a non-executable binary.
So implement our own iteration over $PATH to detect such a case.
Note: this doesn't handle the case where PATH isn't set at all (QStandardPaths implements a fallback)
nor do we implement this for Windows (where chmod -x doesn't really exist as is). I think this is fine,
in the worst case the user will get the other error message, program not found.

Test Plan:
'sudo chmod a-x /usr/bin/gwenview' then try opening a picture with gwenview from e.g. dolphin, see the error message

Reviewers: ahmadsamir

Reviewed By: ahmadsamir

Subscribers: ngraham, meven, kde-frameworks-devel

Tags: #frameworks

Differential Revision: https://phabricator.kde.org/D29170

M  +16   -5    autotests/applicationlauncherjobtest.cpp
M  +11   -8    src/core/desktopexecparser.cpp
M  +42   -2    src/gui/kprocessrunner.cpp

https://commits.kde.org/kio/05cbbf06384bae0cad8de19d659864c0f8dbd651

Comment 3 samoht0 2020-05-31 06:27:57 UTC

(In reply to David Faure from comment #2)
> Differential Revision: https://phabricator.kde.org/D29170
> 
> M  +16   -5    autotests/applicationlauncherjobtest.cpp
> M  +11   -8    src/core/desktopexecparser.cpp
> M  +42   -2    src/gui/kprocessrunner.cpp
> 
> https://commits.kde.org/kio/05cbbf06384bae0cad8de19d659864c0f8dbd651

The commit seems to cause a regression for me:
https://bugs.kde.org/show_bug.cgi?id=422270