Bug 429839 - Executable JavaScript files are executed when activated, not opened in an app
Summary: Executable JavaScript files are executed when activated, not opened in an app
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: git master
Platform: Other Linux
: HI normal
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-11-30 07:57 UTC by Kai Uwe Broulik
Modified: 2020-12-17 04:12 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 20.12.1
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Uwe Broulik 2020-11-30 07:57:25 UTC
SUMMARY
Trying to "Run" instead of "Open" a JavaScript file leads to a cryptic error:

Unknown error code 100
execvp: Error in file format

STEPS TO REPRODUCE
1. Search for a JS file in KFind
2. Click to open it
3. 

OBSERVED RESULT
Aforementioned error message appears

EXPECTED RESULT
File opens in Kate

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.20.80
KDE Frameworks Version: 5.76
Qt Version: 5.15.1

ADDITIONAL INFORMATION
The same happens in Dolphin when clicking "Run" but in KFind I have no choice.
Comment 1 Kai Uwe Broulik 2020-11-30 08:00:13 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?
Comment 2 Nate Graham 2020-11-30 15:12:41 UTC
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".
Comment 3 Méven Car 2020-12-01 09:36:05 UTC
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.
Comment 4 Ahmad Samir 2020-12-02 11:37:49 UTC
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 \&quot;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 \&quot;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 \&quot;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?
Comment 5 Nate Graham 2020-12-02 15:10:48 UTC
I believe so.
Comment 6 Bug Janitor Service 2020-12-03 21:41:01 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/243
Comment 7 David Faure 2020-12-03 22:40:34 UTC
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.
Comment 8 Ahmad Samir 2020-12-04 14:10:17 UTC
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"'...
Comment 10 David Faure 2020-12-12 17:15:59 UTC
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.
Comment 11 Ahmad Samir 2020-12-14 22:53:01 UTC
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.
Comment 12 Ahmad Samir 2020-12-15 16:45:55 UTC
(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.
Comment 13 Nate Graham 2020-12-17 04:12:31 UTC
Fixed by Ahmad Samir in Dolphin 20.12.1 in https://commits.kde.org/dolphin/c03b43b4a1132ca7bc6db4a1583bc8bd1578b44f!