| Summary: | Executable JavaScript files are executed when activated, not opened in an app | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Kai Uwe Broulik <kde> |
| Component: | general | Assignee: | KIO Bugs <kio-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | a.samirh78, faure, kde, kdelibs-bugs, meven.car, nate |
| Priority: | HI | Keywords: | regression |
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/dolphin/c03b43b4a1132ca7bc6db4a1583bc8bd1578b44f | Version Fixed In: | 20.12.1 |
|
Description
Kai Uwe Broulik
2020-11-30 07:57:25 UTC
Seems to happen because the file is marked +x but that didn't cause problems earlier. I don't get why JS files are treated as "executable" anyway. What is it supposed to do? Spawn a NodeJS instance with them? Can confirm. This happens when the executable bit is set and setRunExecutables(true) is set for the KIO::OpenUrlJob. It always tries to execute the file. It seems like we need to disambiguate between "is executable but should be opened in an app when activated" and "is executable and should actually be executed when activated". I guess we should restrict to known executable script mimetypes before trying to run them with "execvp" in KIO::OpenUrlJob. Displaying "Run" in the first place could be fixed the same way. from /usr/share/mime/packages/freedesktop.org.xml, application/javascript is a sub-class of application/ecmascript, which is a sub-class of application/x-executable; and it has:
<magic priority="50">
<match type="string" value="#!/bin/gjs" offset="0"/>
<match type="string" value="#! /bin/gjs" offset="0"/>
<match type="string" value="eval \"exec /bin/gjs" offset="0"/>
<match type="string" value="#!/usr/bin/gjs" offset="0"/>
<match type="string" value="#! /usr/bin/gjs" offset="0"/>
<match type="string" value="eval \"exec /usr/bin/gjs" offset="0"/>
<match type="string" value="#!/usr/local/bin/gjs" offset="0"/>
<match type="string" value="#! /usr/local/bin/gjs" offset="0"/>
<match type="string" value="eval \"exec /usr/local/bin/gjs" offset="0"/>
<match type="string" value="/bin/env gjs" offset="2:16"/>
</magic>
Are you saying it should always be opened as text?
I believe so. A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/243 Alternatively, KFind should call setShowOpenOrExecuteDialog(true), no? This makes me wonder about the usefulness of setRunExecutables though, if all "file manager like" applications should use setShowOpenOrExecuteDialog(true) instead, and "normal apps" (which want to open documents, not run stuff) should call neither. For .js files; the file I was testing with was missing the shebang, adding e.g.: #!/usr/bin/gjs makes it not show the "execvp" error. (In reply to David Faure from comment #7) > Alternatively, KFind should call setShowOpenOrExecuteDialog(true), no? > KFind still uses KRun though. I'll port it... > This makes me wonder about the usefulness of setRunExecutables though, if > all "file manager like" applications should use > setShowOpenOrExecuteDialog(true) instead, and "normal apps" (which want to > open documents, not run stuff) should call neither. It could be useful for users of OpenUrlJob; explicitly calling setRunExecutables(false) could be useful, 'yes, it's the default, but the explicit call is more "peace of mind"'... A setter that only makes sense for one value which is the default value, doesn't have a good enough reason to live. What I'm wondering is whether setRunExecutables(true) makes any sense. I did a general lxr search for setRunExecutables\(true\), removed the 3 useless ones in kdepim, and found one case that maybe makes sense: https://lxr.kde.org/source/kde/workspace/plasma-workspace/applets/icon/iconapplet.cpp#0436 I guess if you add a python script as an icon in your plasma panel, you want it to execute without asking "open as text file or execute" every time you click on it. OK, so that's our use case: application launchers. Dolphin, OTOH, still has too many setRunExecutables(true) in my opinion; file managers should use setShowOpenOrExecuteDialog(true) instead. For dolphin: https://invent.kde.org/system/dolphin/-/merge_requests/141 It seems that the openOrExecute dialog doesn't work with AppImages for some reason https://bugs.kde.org/show_bug.cgi?id=429603, needs some more investigation. (In reply to Ahmad Samir from comment #11) > For dolphin: https://invent.kde.org/system/dolphin/-/merge_requests/141 > > It seems that the openOrExecute dialog doesn't work with AppImages for some > reason https://bugs.kde.org/show_bug.cgi?id=429603, needs some more > investigation. It turns out that bug 429603 only happens if the user had previously selected "run" and ticked "don't show again" in the OpenOrExecute dialog. Fixed by Ahmad Samir in Dolphin 20.12.1 in https://commits.kde.org/dolphin/c03b43b4a1132ca7bc6db4a1583bc8bd1578b44f! |