为什么在Nautilus中截断此文件名？
在Ubuntu中，文件名的“扩展名”，即点（。）后面的部分通常是可见的。 当ls命令清楚地显示完整的文件名时，为什么Nautilus没有显示eclipse.desktop的扩展名？
这是list view ; 不是icon view 。
关于.desktop文件及其特殊function
.desktop文件是特殊文件。 它们代表 GUI中的应用程序，无论是在桌面上还是在Dash / Unity中。 为此，应用程序的GUI名称设置在行中文件的一行中
Name=Eclipse
您可以通过更改.desktop文件中的此行来更改应用程序在Dash和Unity中显示的名称，而无需更改.desktop文件的文件名。 在这种情况下，文件是否可执行是无关紧要的。
如果.desktop文件在你的桌面上，但是，如果它不可执行，它不能用作启动器，原因在souravac的答案中解释，并在其自己的（文件）名称下“显示”：
eclipse.desktop
如果它是可执行的并且在桌面上，则它作为启动器工作，因此它代表一个应用程序。 然后它显示应用程序的名称，如Name=
语言特定名称
如果.desktop文件包含以下行：
X-Ubuntu-Gettext-Domain
该文件甚至显示一个特定于语言的名称，从一个语言文件中获取，然后将在Dash和Unity中显示。
下面是一个复杂的例子：filename = inkskape.desktop，“basic”接口名称= Inkskape，翻译名称= Inkskape矢量图形编辑器
ls命令
在ls命令中纯粹是基于cli的，并且始终显示文件名 。
引用Ubuntu的安全策略 ：
需要执行权限位
应用程序（包括桌面和shell）在以下情况下都不得从文件中运行可执行代码：
- 缺少可执行位
- 位于用户的主目录或临时目录中。
这包括* .desktop，* .jar和* .exe文件。
用户主目录下的有效.desktop文件是什么？
根据Ubuntu的安全策略，当.desktops文件和shell脚本位于用户的主目录中时，必须从这些文件中运行可执行代码。
Nautilus不会将.desktop文件视为有效的应用程序快捷方式，除非它们位于用户的主目录中时具有可执行位。
另一方面，在nautilus的源代码中硬编码它将在.desktop文件中的Name=或Name[$LANG]字段中显示有效的.desktop文件名，忽略文件名和扩展名。 这不适用于nautilus中的.sh或.jar文件。
示例：在新的Ubuntu安装中，每个用户都在其主目录中获取examples.desktop 。 文件名是examples.desktop 。 但在鹦鹉螺中，人们可以将其视为Examples 。 如果您查看.desktop文件，您可以看到以下内容（我只显示其中的一部分）：
名称=示例 名称[AA] = Ceelallo .. 名称[EN_AU] =实施例 名称[en_CA] =实施例 名称[EN_GB] =实施例 ..
您可以检查Eclipse.desktop和smartgit.desktop的权限（尝试ls -la /path/to/filename.extension ）。 前者具有可执行位集，而后者没有。
这就是为什么nautilus将Eclipse.desktop识别为应用程序快捷方式而不显示其扩展名的原因。
如果.desktop文件是可执行的，那么Nautilus会将其识别为桌面快捷方式，并且不会显示文件的名称，而是将字符串设置为文件中Name=属性的值。
在此链接作者“fragos”写道：
不幸的是，如果您在nautilus中打开该文件夹，则会出现.desktop文件，其中包含文件中指定的图标以及文件中调出的文件名。
当他说“文件名称在其中”时，他表示显示的文件名是从内部获取的。 我会说“在设置可执行位时调用文件名”。 他可能是对的，这是不幸的。 奇怪的是，我有一些设置了执行位，而另一些则没有。 没有设置执行位的那些不是不幸的原因，但我不知道为什么我很幸运。 当该位置位时，它可能被认为是一个怪癖或错误。