GNOME Bugzilla – Bug 742935
Nautilus 'File' application fails to recognize and launch shell scripts
Last modified: 2017-08-31 09:20:40 UTC
I am running a currently updated version of Fedora 20. Nautilus 'file' application does not execute shell scripts by clicking on the icon for the script file. The file is automatically opened in gedit. Enabling the checkbox: "Allow executing file as program" does not change the file mode to executable as verified by the CLI command: ls -l /path/filename-of-shell-script Setting the file's mode to executable using the CLI still does not prompt the nautilus 'file' application to execute the script as a shell script. Using the 'Properties->Open With' browser does not provide a means of selecting /usr/bin/bash' as an application. Also the 'add' function which normally provides a way to browse through the filesystem for an application is ghosted out. An example is this script located in my $HOME directory; ls -l Oblivion-Shell-Launch-obse.sh -rwxrwxr-x. 1 myname 500 153 Jan 14 10:43 Oblivion-Shell-Launch-obse.sh #!/usr/bin/bash cd /home/myname/.wine/drive_c/Program\ Files/Bethesda\ Softworks/Oblivion/ #su -c 'setsebool wine_mmap_zero_ignore=on' wine obse_loader.exe This script executes fine from a CLI. It seems to me this worked in earlier version of Nautilus but I can't confirm that now.
I don't see a bug here but rather a protection to not easily trigger malicious scripts.
(In reply to comment #1) > I don't see a bug here but rather a protection to not easily trigger malicious > scripts. In that case, what is the point of including an option in the 'properties' to "Allow executing file as program"? Also doesn't the file browser respect file permissions? That is to say, if someone has breached my login they can execute my scripts from a shell just as easily so you are not saving me any security by disabling features of the file browser.
So, marking a file as executable is not the same as allow executables to start from nautilus. The former is just a property which can be useful for some developers, instead of using chmod. The latest is, for any executable file, allow it to open in nautilus. Although I can see the confusion/clash of terms and concepts, I prefer to go in the safe way and keep it like that.
*** Bug 785014 has been marked as a duplicate of this bug. ***
After this time, I don't understand much the logic in my last comment. I'm reopening the bug to reconsider it.
I honestly am not sure what the rationale is not to execute scripts to be fair -- that may have been a decision from Alex a long time ago? I'm not even sure that it's intentional...
There is an option for this in the Preferences window, in the Behavior tab: Executable Text Files (·) Display them ( ) Run them ( ) Ask what to do (In reply to Bob Goodwin from comment #0) > It seems to me this worked in earlier version of Nautilus but I can't > confirm that now. The default option was changed in commit 72d6c7ce7febd5739097896b2ea16cf730887e9a from 'Ask what to do' to 'Display them'. If you never changed that option before, it's possible that the the change in default affected your installation. Can you confirm if you can run the script after choosing the "Ask what to do" option in the Preferences?
Yes, what a noob ;-) I did find the option and was able to switch to the behavior I would like to see. I am also running on RHEL 7.4 now, which is using Nautilus 3.22.x. So maybe, as a suggestion coming out of this: Why not ask the user with the dialog when he didn't make a decision yet. And allow to set the default a checkbox in the dialog ("Remember choice"). Adding an context menu entry (execute as script) when the user chooses to got for "edit" by default. This would give a proper flow IMHO but make this transparent to the user in some way. And still allows users to execute the script if the choice was made to edit by default.
(In reply to Jens Reimann from comment #8) > Yes, what a noob ;-) Not at all. Users are not to be blamed for ignoring there was an option in Preferences all along if they only knew the previous default. > So maybe, as a suggestion coming out of this: Why not ask the user with the > dialog when he didn't make a decision yet. That would have the same problem that the previous default. If you read the commit message, the point in changing the default from "ask" to "display" was exactly to avoid asking advanced questions by default for everyone. At most, it could have been nice if there was a 1-time message informing that there is an option in Preferences to run scipts, but it's a bit to late for this now, the change happened 5 years ago. So, I'm closing this as NOTABUG because everything is working as expected. There was indeed a problem with communicating this change and the existence of an option in Preferences, but it's hardly fixable now as far as I can see. > Adding an context menu entry (execute as script) when the user chooses to > go for "edit" by default. Good idea. I'd be more radical: remove the option from preference, always "Open" on double click, and always have "Run in Terminal" as context menu entry. I'll add this idea on bug 598671.