Nautilus Ability To Launch Binaries Or Scripts To Be Reverted, Might Be Implemented Differently
It looks like the decision to remove the ability to run binaries and scripts from Nautilus file manager will be reverted. The change comes after some use cases appeared that the developers agreed they need to support, "especially for enterprise and content creators".
One such use case that was mentioned as a reason for reverting this is a small "if then that" script for building HTML and PDF files, which uses Zenity to display a dialog, as well as notifications to display the progress.
I find the use case being used as an example a bit weird because that's certainly not something common, like a self-extracting game script for instance.
While the current merge request (submitted by the same developer that removed the ability to run binaries and scripts earlier this week) allows running binaries and scripts as before, there are also some improvements to Nautilus' binaries and scripts handling that's being discussed. What's currently proposed is to treat this feature as "legacy support", adding a "Run as Program" context (right click) menu, instead of allowing double clicking a binary or script.
In the proposal, the "Run as Program" menu item should be displayed even if the file is not marked as executable, in which case a dialog is displayed that allows the user to mark the file as trusted and make it executable, and only then allow running it:
Clicking "Run" will close the dialog and open a Terminal window in which the binary is executed. That means a Terminal will be used, even for programs that have a GUI. This is not exactly ideal, so proposals were made later on in the discussion, to only show the terminal initially, and automatically close it after running the binary, as a way to provide the user with feedback that something happened.
According to the bug report that explains this change, adding "Run as Program" to the context menu is seen as safer because double clicking it doesn't allow the program to run, while also providing an alternative solution. It also removes the need to know how to make a file executable.
This new "Run as Program" legacy implementation is currently being discussed here, and is not the final design decision.
This doesn't include information on what will happen to running *.desktop files though.
For *.desktop files there's a different proposal which mentions running the files similarly to scripts and binaries, from the context menu, with a confirmation dialog that could warn about the risk and set the executable bit, but without opening a terminal window.
One such use case that was mentioned as a reason for reverting this is a small "if then that" script for building HTML and PDF files, which uses Zenity to display a dialog, as well as notifications to display the progress.
I find the use case being used as an example a bit weird because that's certainly not something common, like a self-extracting game script for instance.
While the current merge request (submitted by the same developer that removed the ability to run binaries and scripts earlier this week) allows running binaries and scripts as before, there are also some improvements to Nautilus' binaries and scripts handling that's being discussed. What's currently proposed is to treat this feature as "legacy support", adding a "Run as Program" context (right click) menu, instead of allowing double clicking a binary or script.
In the proposal, the "Run as Program" menu item should be displayed even if the file is not marked as executable, in which case a dialog is displayed that allows the user to mark the file as trusted and make it executable, and only then allow running it:
 |
| Image credits: António Fernandes (@) |
Clicking "Run" will close the dialog and open a Terminal window in which the binary is executed. That means a Terminal will be used, even for programs that have a GUI. This is not exactly ideal, so proposals were made later on in the discussion, to only show the terminal initially, and automatically close it after running the binary, as a way to provide the user with feedback that something happened.
According to the bug report that explains this change, adding "Run as Program" to the context menu is seen as safer because double clicking it doesn't allow the program to run, while also providing an alternative solution. It also removes the need to know how to make a file executable.
This new "Run as Program" legacy implementation is currently being discussed here, and is not the final design decision.
This doesn't include information on what will happen to running *.desktop files though.
For *.desktop files there's a different proposal which mentions running the files similarly to scripts and binaries, from the context menu, with a confirmation dialog that could warn about the risk and set the executable bit, but without opening a terminal window.
