GNOME Bugzilla – Bug 144585
Unable to launch custom applications in home dir by their name.
Last modified: 2020-11-06 20:19:32 UTC
Steps to simulate the problem:- 1. Create your own application say myapp in the home directory say /home/test 2. Invoke run application dialog using Actions -> Run Application. 3. Specify myapp in run application dialog. Observation and bug: An error dialog appears saying, "Cannot display location 'file:///home/test/myapp" Details: There is no default action associated with this location." This error message can be confusing to the end user. i.e. The user would expect run application to execute his/her binary instead of trying to display it.
The error message needs to modified to provide more clarity to the user. i.e. currently, when the display of the file fails, the error message only communicates the display failure. However, internally the failure to display a file occurs after the failure to launch it (or find it in the PATH). So, the user should be notified in a manner which depicts that either one or both of the two failures occured, due to which it could not launch/display the file. e.g. Cannot execute command 'myapp' or display location 'file:///home/test/myapp'. This way, 2 things would become implicitly clear to the user:- 1) Just typing "myapp" is not sufficient for execution. i.e. either the complete (absolute) path should be provided or the binary be moved into the standard path being used by shell. 2) The location url 'file:///home/test/myapp' cannot be displayed either since it's a binary (The user would not expect a binary to be displayed anyway). Now just a quick look at the other option:- Could we execute binaries which are present in the home path, using the run dialog? (since auto-complete feature prompts the user on the available binary files as well, in the home directory). Executing binaries which lie in the home path (and not in shell PATH), without specifying the absolute path, is not possible using shell. This is a behaviour consistent with all applications which also use shell for execution of binaries. Trying to execute binaries which lie in non-standard path, would be a bad hack. So, the best solution available was to improve the error message to get closest to achieving clarity for the user.
Created attachment 28822 [details] [review] Patch to fix the problem.
You should be able to run any program by specifying its path, IMHO. Even if its not in $PATH. Frank, what do you think?
Hey Mark, I agree and it is possible even now. i.e. when you specify the absolute path of a binary, then irrespective of it being in $PATH, it will be run. The patch only improves the error message to handle a particular situation when a user specifies only the binary name without giving it's path, and this binary is not in $PATH either. Thanks.
I'm not sure. You could call it a safety feature that we don't execute a file unless it's in $PATH or you give the absolute path. That would prevent users accidentally running an executable file that they got from somewhere, when they actually just want to view it. Regarding the patch, I think you need to escape the command before using it in a message. Mark, I attached a patch to bug 133243. Let me know what you think.
Created attachment 28923 [details] [review] Modified patch. Please review the modified patch.
I'm not sure the wording is better with this patch. The error dialog will say: "Cannot execute command 'myapp' or display location 'file:///home/test/myapp" Details: There is no default action associated with this location." The details given are only related to the "location part" of the error. But I don't know how we can improve this...
What about "Details: There is no [default] application associated with the attempted action." If we know this is an executable, I think we should tailor a message specific to this case, and give the user an option of executing it anyway (and then, perhaps, remember the decision for this specific executable in the future).
I agree with Vidar that part of the right approach to solving this is to give people the option of launching it, with an appropriate warning that it may or may not be the one they expect- something like 'this program was not installed by your administrator and may be unsafe' or something like that maybe? Also worth noting that string freeze is coming up on us- this needs to happen soon...
Comment on attachment 28923 [details] [review] Modified patch. Seems to be agreement that the wording still needs work.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.