ahmadsamir added a comment.
In D29170#657689 <https://phabricator.kde.org/D29170#657689>, @dfaure wrote: > In D29170#657450 <https://phabricator.kde.org/D29170#657450>, @ahmadsamir wrote: > > > I don't think you need to go out of your way to support custom setups, after all it's quite simple for the user to edit the .desktop file and specify the path to the executable. Even from the xdg thread, they were talking about installing a virtual machine guest stuff, which is something the user only has to do once, whereas, from my POV at least, a .desktop file is more for things your run frequently/on a regular basis. > > > One use case could be running software on a USB key. The desktop file there doesn't know the full path, but a relative one. > > > It would simplify the code, and would be consistent with how a shell would run a program; indeed a binary in the current dir has to be explicitly prefixed with ./ > > I'm not sure if now you're advocating to support "./foo" or no support for relative executables at all. The latter, i.e. not handling the relative path. >> That also means that the original code trying to find the executable in the current dir never really worked > > You keep reading it that way, and I keep saying that code was assuming "realExecutable" is an absolute path. As my (new) comment in the code says, it actually is one, if the program was found (and is executable). > What happened with not-found-therefore-still-relative executable names in there was purely accidental (and fixed by this commit). Yep, resultingArguments() would resolve/get the full path. >> because "current dir" is most likely where the _KIO executable_ exists (I tested with qt-creator and QDir::current() is indeed where the compiled binary exists). So not that useful. > > Worse, if you start "dolphin /tmp" from your $HOME (using konsole), then QDir::curren() is $HOME, completely unrelated to what dolphin is showing. Current dir is indeed irrelevant for a .desktop file, it only makes sense from the CLI or for actual executables looking for .so files. > I got no reply on k-f-d but Albert Astals Cid on IRC was of the opinion of "stick to the spec, don't support relative executables in any way", which is a fair point. > If you agree too I can just revert to not supporting relative paths at all. It all came from what I thought was a request from you in the first review, and that old request on xdg. Part of the issue is, if that feature is implemented here but doesn't get adapted by other DE's/file managers too, 3rd parties won't use it as they usually want a one-size-fits-all solution (which doesn't exist....), and from what I see with a shell script is much more robust for those 3rd parties. INLINE COMMENTS > dfaure wrote in desktopexecparser.cpp:465 > But if we do that, a non-executable file gets ignored here and we don't get > the warning that this commit is all about. > > It would all be much simpler [for this custom purpose] if findExecutable > didn't check the executable bit ;-) Then we'd have one full path to check > ourselves. Instead we have to duplicate the PATH lookup. I'd like to avoid > having to also duplicate the current-dir-of-desktop-file lookup and the > libexec lookup. > But if we do that, a non-executable file gets ignored here and we don't get > the warning that this commit is all about. Righto. The isExecutable() check is done in KProcessRunner. And I echo that request, findExecutable() would be slightly more useful if it reports that it found a file with that name but it's not executable; the QStandardPaths API doesn't offer any other way of searching PATH, so the only method it has should report such a case. I am not sure if upstream would take a patch for that... REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D29170 To: dfaure, ahmadsamir Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
