我最近重新安装了 64 位 Ubuntu（之前使用的是 32 位）。我的主文件夹位于一个分区上，系统位于另一个分区上。因此，当我重新安装时，我保留了旧的主文件夹。我的问题是，现在，当我尝试运行使用 SDL 的 c++ 可执行文件时，Nautilus 告诉我：
Could not display "program"
There is no application installed for "shared library" files.
Do you want to search for an application to open this file?
所以问题似乎是 nautilus 认为它是一个“共享库”，但我不知道如何解决它！
我怎样才能让它被识别为普通的可执行文件？
file program返回 ：
program: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=39330e8ffbc9d3c5392da418d7fabecbb32334eb, stripped
并mimetype program返回：
program: application/x-sharedlib
答案1
答案2
我认为 Nautilus 团队不会很快解决这个问题。问题出在 Nautilus 和 file/libmagic 项目之间。file/libmagic 无法可靠地区分共享对象和可执行文件。因此，当我有时需要从 Nautilus 执行二进制文件时，我会将其拖到终端窗口中或创建一个单词脚本。但是，当我需要更频繁地执行二进制文件时，我会切换到另一个文件管理器：Dolphin 或 Nemo。据我所知，Dolphin 只是执行具有“执行”权限的任何文件。Nemo 在共享对象的情况下会询问：“使可执行文件并运行”或“选择一个程序”。
答案3
我创建了一个脚本“RunFromThunar.sh”
#!/bin/bash
exec $1
... 在 Thunar 中，我将“共享库”与此脚本关联起来。它起作用了！
它在 Nautilus 中也一定能以同样的方式起作用。
答案4
我将 Ubuntu 更新到 19.10。这个问题没有任何改变。Nautilus 仍然拒绝运行 64 位可执行文件。即使在修复了 file/libmagic 之后也是如此。现在编译后的可执行文件被报告为“ELF 64 位 LSB pie 可执行文件”，而不是像以前那样“ELF 64 位 LSB 共享对象”。然而，Nautilus 团队并没有改变他们的方法，我不明白他们的理由。如果他们想保护用户免于意外点击恶意软件文件，那么一个简单的弹出警告就足够了。（请参阅启动未签名程序时的 MS Windows 警告。）但是，如果他们真的想完全禁止启动恶意软件，那么这根本不可能。有很多方法可以欺骗没有经验的用户。对
我来说更糟糕的是 Nemo（版本 4.0.6）停止提供“制作可执行文件并运行”。（我在 19.10 之前主要使用 Nemo。）要么 Nemo 团队与 Nautilus 一样担心安全问题，要么他们只是从 Nautilus 复制了部分代码。 Dolphin 不会失去常识。但是，我还没有准备好在 GNOME 环境中完全切换到 Dolphin。
我想再次提到当我需要从文件管理器运行二进制文件时。当我安装下载的程序时，我不需要它。然后桌面启动器是最合适的选择。但是，当我在开发或研究时，我可以保留同一程序的编译可执行文件的不同版本。然后我需要从文件管理器运行二进制文件。
看来 Nautilus 团队不会改变他们的方法。最后，我找到了一个对我来说最好的解决方案。我创建了一个桌面启动器，它获取文件名并将其作为命令传递给 shell。以下示例：
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Run Executable
Comment=Run Executable
Exec="/bin/sh" -c %f
Icon=application.png
Terminal=false
我将此启动器保存在 ~/.local/share/applications 中，并命名为 RunExecutable。因此，我可以从“打开方式”菜单中的“所有应用程序”列表中选择此启动器。这让我的生活变得像以前一样舒适。因此，我在 Nautilus 和最新的 Nemo 中解决了这个问题。但是，我并没有解决与 Nautilus 团队的分歧。Nautilus 应该以直接的方式运行可执行文件。