run executable file when it has executable attribute

[Xeverous]

 * Nemo version (nemo --version)
4.4.2
 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...)
Mint 19.3
 * 32 or 64 bit
64

Issue

This is rather stupid problem, but I can not find a way to run any executable from nemo. There is no such option on the right click menu. Double clicking only gives the dialog that the file type is unknown and asks to cancel or choose another program to open (the binary file) with.

The binaries I compile have -rwxrwxr-x attributes.

[Neinei0k]

I think you might have the same problem as I do. It appears that nemo also cares about the mime type of the file. In my case, it is application/x-sharedlib, so it sees it as a shared library. I'm not familiar with the structure of ELF files but apparently some executable files can look like shared libraries, since both file and mimetype also return the same mime type. BTW, I have Linux Mint 19.3 and Nemo 4.4.2. I'm not sure, maybe it is already fixed, or the problem is in some, possibly outdated, configuration files. I also don't know whether nemo supposed to run some of the files with this mime type, or the mime type was just incorrectly determined.

[Xeverous]

I downloaded caja and it has a different popup - it displays what you mentions. In caja, the binary is classified as a shared library. What you describe is exactly this: https://stackoverflow.com/questions/45329372/ubuntu-recognizes-executable-as-shared-library-and-wont-run-it-by-clicking which is easily solveable.

nemo has a different problem, it has no launch options at all. Apparently it has this change (which I greatly dislike): https://www.omgubuntu.co.uk/2018/05/nautilus-remove-ability-launch-binaries-apps

[Neinei0k]

This solution is for developers, and I'm not a developer of the applications with this problem (gdevelop and Defold). About the second link, I don't know whether this change was implemented in nautilus, but it does not seem to be implemented in nemo, since I can clearly run applications by double clicking. Nautilus had this bug years ago https://bugzilla.gnome.org/show_bug.cgi?id=737849. It seems that your second link says how they solved it, they completely removed the ability to launch applications from nautilus.

[xenopeek]

Would either or both of you point to or attach a file you've confirmed this issue for, to test with.

[Neinei0k]

As I've said, in my case the problem is with two game engines: GDevelop and Defold. Defold can be downloaded from defold.com. It is almost 400MiB. There is no tarball for new versions of GDevelop. The tarball for older version, can be downloaded from here. It is 113.9MiB. Defold executable, is just several MB Defold.zip. Obviously you can't start an application with it, but it should be enough to see the problem. In both cases Nemo shows MIME type application/x-sharedlib. By double-clicking, it shows a message that the file type is unknown and asks to choose a program to open the file with. Both programs can be run from the command line without problems.

[Jeremy7701]

A small example would be /bin/ls ;)

[Neinei0k]

Good catch. I don't think I've ever looked into the /bin directory from nemo. Turns out that a lot of executable files there are seen as shared libraries.

[xenopeek]

I tried to run /usr/bin/gnome-terminal.real as a test because that will actually do something when run, unlike /bin/ls. Indeed Nemo won't run it. Neither will Nautilus or Thunar. That many executables in /bin and /usr/bin have a MIME type of application/x-sharedlib ("shared library") is common across other distros (I looked at Ubuntu and Arch Linux). There's an older issue about this weirdness: https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1639531. That's not something that should be solved in Nemo.

Of those I tried only Dolphin offers to run shared libraries:

You can make other file managers do something similar as Dolphin if you have a need to start GUI programs (compiled as shared libraries) from your file manager but don't want to create a .desktop entry for each program as you normally would. You'd create a generic .desktop entry for application/x-sharedlib binaries. To do so create the file ~/.local/share/applications/run-executable.desktop and put this in it:

[Desktop Entry]
Type=Application
Name=Run Executable
NoDisplay=true
Icon=application-x-executable
Exec=/bin/sh -c 'zenity --question --title="$0" --text="What do you wish to do with this executable file?" --no-wrap --ok-label Execute --cancel-label Cancel && "$0"' %f
Terminal=false
MimeType=application/x-sharedlib

Then right-click a shared library file, select Open With Other Application, highlight our Run Executable and click Set as default. Next time you double-click a shared library file you get this dialog:

[Xeverous]

That many executables in /bin and /usr/bin have a MIME type of application/x-sharedlib ("shared library") is common across other distros [...] That's not something that should be solved in Nemo.

What do you think, who's responsibility it is then? Is the identification as a shared library wrong, or is some software in the middle way misbehaving?

[Jeremy7701]

For Firefox installed as (/usr/bin/firefox -> /opt/firefox/firefox)
$ file --mime-type /opt/firefox/firefox shows /opt/firefox/firefox: application/x-executable
Double-clicking the file in nemo fires up the current version of Firefox in the normal way - it might seem that GUI only programs are OK, but:-

For example nemo doesn't know how to open the GUI CD/DVD disk creator, K3B - even though the CLI can run that program to startup the GUI program normally.
$ file --mime-type /usr/bin/k3b shows /usr/bin/k3b: application/x-pie-executable

Surely it is for the creator of the program to choose the mime-type?

[SvenGeier]

That many executables in /bin and /usr/bin have a MIME type of application/x-sharedlib ("shared library") is common across other distros [...] That's not something that should be solved in Nemo.

What do you think, who's responsibility it is then? Is the identification as a shared library wrong, or is some software in the middle way misbehaving?

Let me re-open this line of thought: the fact that "many executables have a certain mime-type" should not, of course, be solved in nemo. But the fact that nemo doesn't execute many executables (because they have that mime-type) probably should.

If I use a file manager to go to /usr/bin and double-click a program like xedit then I expect that program to start. If this doesn't happen for some executable, then there's something wrong with that executable. If it doesn't happen for ANY executable then there's something wrong with nemo.

[Jeremy7701]

If you used a CLI file manager, you might reasonably expect xedit to be run.
A GUI file manager should not try to execute a file, it should instead supply the file as an input to a program (ideally defined by the mime-type of the file).

For example, nemo can run scripts by supplying the file as input to bash (or whatever).

[mcarans]

I've just run into this too when running kitty, a terminal. It is treated as a shared library and won't execute.

What is it that the author of the terminal needs to change in order for it to be recognised in Mint as an executable so that it can be executed? I could raise it as an issue against that project in GitHub.

[Jeremy7701]

A .desktop file?

[SpencerTinnin]

Save this in ~/.local/share/nemo/actions as Execute.nemo_action. That should add an "Execute File" option when right clicking on files with application/x-sharedlib and application/x-shellscript MIME types. There's a line you can uncomment to make it show on every non-directory file instead.
Execute.nemo_action.txt (Be sure to remove ".txt" from the name, Github wouldn't let me upload the file without it)

[SvenGeier]

I, the user, determine what is and isn't an executable file and I determine it by setting the x-bit in the file permissions. Not the person who wrote it, not the person who wrote the file manager, not the person who wrote some "mime-type utility".

I, and I alone, get to decree what is and isn't executable -- everything else

• Breaks POSIX
• Invites every hacker in the universe

If you used a CLI file manager, you might reasonably expect xedit to be run. A GUI file manager should not try to execute a file, it should instead supply the file as an input to a program (ideally defined by the mime-type of the file).

No.

This statement is categorically false.

The very meaning of the phrase "chmod +x filename" is "This file is different from other files, it contains code that can be executed in some form". I have no quarrels with some right-click menu that offers me nine hundreds options for what I might want with a file - open it in an editor or display the contents on screen or submit to pornhub or whatever you can think of. But the thing an executable file does by default is "being executed". That's its purpose. Without doing any kind of research I can state with complete confidence that 99.99% of accesses to /usr/bin/xed are to execute it.

As long as Nemo does not even have THE OPTION to choose "execute this file" when I click on an executable, Nemo is broken. A file manager that does not have an option to execute an executable file is as broken as a file manager that doesn't have an option to edit a editble file or copy a copyable file or browse a browsable directory. It is failing at its most basic functionality.

For example, nemo can run scripts by supplying the file as input to bash (or whatever).

[Jeremy7701]

When you say "[you] decree what is and isn't executable" - what does that actually mean?

If you attempt to run a file doesn't have an x bit set, it's definitely not going to be executed - although it might cause a different file to be executed which takes the first file as data. This is how a GUI editor usually works.

And if your file has an x bit set, it might not get executed (in the usual sense) - if its a script then it's going to just cause various programs to execute such as env, bash or whatever.

Even a plain binary file (with +x) needs to run in some kind of environment.

[SvenGeier]

When you say "[you] decree what is and isn't executable" - what does that actually mean?

chmod +x

If you attempt to run a file doesn't have an x bit set, [...]

And if your file has an x bit set, [...]

So we agree that there's a difference here, right?

When I double-click a text file in Nemo and the x-bit is set, it'll pop up an alert box with a couple options and asks me what I want to do with this file -- display it, edit it, or, yes, run it. Because nobody needs an explanation what it means to "run an executable script". All that blah-blah is just semantics -- if you've spent more than three days around Linux you know the meaning of the word "run" for an executable text file.

When the x bit is NOT set, the text file just gets opened in an editor instead.

If I want yet-other-options, I can right-click and choose those.

But when I do the EXACT SAME THING with an actual executable (ELF binary) with the x-bit set, then Nemo will

• NOT offer me to run it
• NOT offer me a right-click option to run it

Actual, executable files with the actual x bit set cannot be actually executed by Nemo (even though text files with the x-bit set can!) It's not even an option.

That is just broken software.

Even a plain binary file (with +x) needs to run in some kind of environment.

[Xeverous]

I agree with @SvenGeier. All this "safety precautions" are just inconvenience for the user. If a user wants to execute a binary executable file, do make it possible.

[Jeremy7701]

Something like this?

[xenopeek]

The issue is confirmed solved in shared-mime-info version 2.1 (the related upstream bug report):

Fix application/x-sharedlib vs application/x-executable confusion for PIE executables

Ubuntu 22.04 LTS has that version and I confirmed it no longer incorrectly labels PIE binaries as application/x-sharedlib, and Nemo will run such files as expected. So Linux Mint 21 won't be affected by this issue.

[Unixware]

So Linux Mint 21 won't be affected by this issue.

bug still on effin LMDE .... oh well..

[f4biopedro]

the command:
apt install shared-mime-info
solved this issue for me