Version: 1.6.1 (using KDE 4.6.3) OS: Linux By default dolphin executes an application/x-shellscript when (double)clicked. Although the application preference order in the file associations dialog in system settings clearly states that for example kwrite should be used. Nautilus does the right thing and calls kwrite. You don't have to add an annoying question dialog like nautilus has per default, just add an opt-out in dolphin, please. Reproducible: Always Steps to Reproduce: (double)click on script Actual Results: script executed Expected Results: application defined in 'File Associations' opens script OS: Linux (x86_64) release 2.6.39-1.dmz.1-liquorix-amd64 Compiler: gcc
Still present in 4.7.0 Actually this bug is CRITICAL for a small script can delete all my data if accidentially clicked upon.
*** Bug 268666 has been marked as a duplicate of this bug. ***
Still present in 4.8.2 really fcking annoying!
Happens also with application/xml now. Konqueror does it right, Dolphin doesn't. But Konqueror executes scripts too. So is this a different bug?
Yes XML is unrelated to executables, please open a different bug for that (whatever "doesn't do it right" means). About the issue of scripts: KRun (an internal class) executes scripts, programs and desktop files by default. This happens before looking at mimetype associations. So technically it's a not a bug, but I can see how it can be an annoyance, for lack of a configuration option for this (there are certainly many people for whom it's a feature, e.g. I added scripts for my secretary to run this way, she doesn't need to edit them). So the solution would be a checkbox in the dolphin "behavior" page (also visible in konqueror). I started to implement it, but I realized that with the current underlying mechanism (KRun), it would have to be called: "Left click executes scripts, programs and desktop files". Would that be OK, or did you have in mind a checkbox for scripts only, and letting left click execute programs and desktop files in all cases? (I don't think this should be configurable in the file associations module, you'd have to adjust many mimetypes, one for python scripts, one for perl scripts, one for shell scripts, etc. etc.) The alternative I have in mind would be a specific setting for scripts (because indeed they can be edited, as an alternative to being executed), unlike binaries. Hmm, well desktop files too, could be edited, but the use case is a bit different (they are just "shortcuts").
Yes it's no technical bug, but a behavioral. Apart from mimetype settings we have the execute bit. Currently the execute bit is deemed more important than mimetype settings. While this might help new users coming from windos or something to feel at home, it represents a big entry hole for all kinds of misery. For example scripts accidentially deleting data or 'viruses' being executed. Since all scripts, ELF and desktop metafiles are almost equal executables in the UNIXoid world (correct me if I'm wrong), the decision whether they are to be executed by default (if x bit set) or to be opened according to mimetype settings must be made for all of these executables (and the ones I forgot) together. Therefore I think that Your idea of a "Left click executes scripts, programs and desktop files" checkbox is the best to go. This is solely dolphin's business, right? If yes the checkbox should be added to it's preferences. If not it should be in a central place. I further suggest the checkbox to be disabled by default. Maybe a tooltip informing of the execute bit should be added to the checkbox. Something like this: "Only scripts, programs and desktop files that have the executable permission set are affected by this option. Others are never executed directly". Of course desktop files are currently executed without the x bit. Maybe that should be changed. Maybe it's not that easy, I don't know. Too bad I can't change the code myself. Yet :)
Nautilus has had the "don't execute scripts" checkbox option since forever. For KDE4, the workaround is to hack the freedesktop mime config as follows: edit /usr/share/mime/packages/freedesktop.org.xml and find the line that starts the shellscript section: <mime-type type="application/x-shellscript"> then scroll down to find this line within that section: <sub-class-of type="application/x-executable"/> then comment it out like so: <!-- <sub-class-of type="application/x-executable"/> --> save that, then compile it with this command: sudo update-mime-database /usr/share/mime
Wow, good to know a workaround could be so simple. Wish I would have known more about MIME.. Thank you! Still a bug though, I think.
You're welcome. I shouda added "restart the desktop" to the end of that guide. The other thing I should mention is that method will disable _all_ kde mime-related shellscript execution, including any shellscripts that you place in ~/.kde/Autostart, and will pop them up in the editor instead. Those need to be replaced with freedesktop "link to application" files, created via the context menu.
Which sadly pretty much breaks KDE for me. I can't do much after it booted. It seems as if kded doesn't start or hangs, because its settings won't open and I can't use shortcuts plus long freezes and other weird stuff. Which are exactly the symptoms of another bug where kded didn't load (not to blame here). So there seems to be inherent dependance in KDE on script being directly executable. Therefore I do not recommend hacking the mime-type of shell scripts! I would still rather like a simple checkbox in dolphin. Or even better: action according to my setup in "File Associatons". Nice try though ;-)
That's unfortunate. That method has worked fine for me on several KDE4.x versions on three different PCs. Failed attempts to run scripts should give themselves away by popping up in the editor.
> Therefore I think that your idea of a "Left click executes scripts, programs and desktop files" checkbox is the best to go. Good, then my patch is finished. Needs an additional fix for konqueror, though, but it works in dolphin, in my tests. Does anyone want to test it? (I only tested it with one .sh file, please test desktop files, executables, etc.) http://www.davidfaure.fr/2012/dolphin_option_executescripts.diff
still present in kubuntu 13.04 and kde 4.10.2
*** Bug 322575 has been marked as a duplicate of this bug. ***
The patch looks reasonable. Thanks David! I'm wondering if we could make it even better by adding a Nautilus-like dialog (see bug 172038) that offers * Open with the associated application * Run * (maybe "Run in Konsole") * Cancel when clicking an executable file, with a "do not ask again"-checkbox, of course? This bug is so old already that we should really solve it sooner rather than later. There are various patches in some places already (comment 12, bug 225563, https://git.reviewboard.kde.org/r/107086/), but nothing ever happened because there was never enough momentum to get them to ReviewBoard and/or get some testing by users :-(
I think this is a case of the wrong default behavior being chosen. If the default behavior had been to open the associated application, and it was entirely up to the user to create actions to run executables, I don't think we would ever have seen even one bug report or feature request about it. I understand if it's too late to switch the default behavior on everyone, but as far as I'm concerned, that is the default behavior inherent to the entire structure of metaphors that underly "File" "Managers" (note: two terms that we are using metaphorically, not literally) and "Desktops" altogether. The File Manager is your access to your "files". Part of the underlying contract that gave rise to file formats and dedicated viewers and "opening" and "reading" states that my substitute for "picking up and reading" a file is double clicking on it. We should get as close to that as possible.
Still present in KDE 4.13.0, Kubuntu 14.04. Dolphin is meant to be kind to users and newbies with plenty of "confirmation prompts", but here it executes scripts that might damage the system where you might expect an editor. Nautilus has always had the "do not execute scripts" check-box and Dolphin should too, with execution being a context-menu option. I see that a patch has been provided in this thread, so it'd be nice if this could be expedited.
Patch to fix this: https://git.reviewboard.kde.org/r/120171/
Git commit 6fe41269df673215b88b52571b574ed575d81e6f by Arjun AK. Committed on 28/10/2014 at 13:21. Pushed by arjunak into branch 'master'. Get user's permission before executing scripts or desktop files This commit makes KIO show a dialog box asking the user what to do (either open it using a text editor or execute it) when he clicks on a script or a desktop file. REVIEW: 120666 M +1 -0 src/widgets/CMakeLists.txt A +64 -0 src/widgets/executablefileopendialog.cpp [License: LGPL (v2+)] A +47 -0 src/widgets/executablefileopendialog_p.h [License: LGPL (v2+)] M +62 -3 src/widgets/krun.cpp M +15 -0 src/widgets/krun_p.h http://commits.kde.org/kio/6fe41269df673215b88b52571b574ed575d81e6f
Git commit 70cd19a70e045b6346c8e35d18d6742141ebd0b4 by Arjun AK. Committed on 01/11/2014 at 11:11. Pushed by arjunak into branch 'frameworks'. Enable KRun's script execution prompt. This commit enables KRun's script/desktop file execution prompts, which is shown when the user launches an executable script or a desktop file. This is done so as to prevent the user from accidentaly executing programs. A checkbox to enable or disable the prompts is also being added to the preferences window REVIEW: 120171 M +2 -1 dolphin/src/dolphinviewcontainer.cpp M +16 -0 dolphin/src/settings/general/confirmationssettingspage.cpp M +1 -0 dolphin/src/settings/general/confirmationssettingspage.h http://commits.kde.org/kde-baseapps/70cd19a70e045b6346c8e35d18d6742141ebd0b4
Still present in KDE 4.14.6, Kubuntu 15.04. Soooo... when does the above fix actually make an appearance?
With the Kubuntu 15.04 explained at the Kubuntu Forums: https://www.kubuntuforums.net/showthread.php?67996-Bug-275405-Dolphin-ignores-file-association-for-scripts-but-executes-them&p=371071&viewfull=1#post371071