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

David Faure noreply at phabricator.kde.org
Sun Apr 26 16:47:34 BST 2020


dfaure added a comment.


  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.
  
  > 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).
  
  > 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.
  
  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.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D29170

To: dfaure, ahmadsamir
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200426/03e6553a/attachment.html>


More information about the Kde-frameworks-devel mailing list