In Ubuntu the "extension" to a file name, that is, the part after the dot (.) is normally visible. Why is Nautilus not showing the extension of eclipse.desktop when the ls command clearly shows that is the full file name?

This is the list view; not the icon view.


  • 9
    Simply because . desktop files are recognized as application shortcuts. No great mystery there. Feel free to explore Nautilus source code to find how exactly it's done. – Sergiy Kolodyazhnyy Dec 7 '16 at 5:34
  • 2
    By that reason, smartgit.desktop is not an application shortcut. What is smartgit.desktop? – H2ONaCl Dec 7 '16 at 5:38
  • 6
    For it to be recognised that way, it also has to be executable, IIRC.. – muru Dec 7 '16 at 5:51
  • This seems unjustified. Executable bash scripts do not have this problem. A "binary" executable like java does not have this problem. To experiment I renamed java (a file that is executable) to x.x to demonstrate that the file name is not truncated. – H2ONaCl Dec 7 '16 at 7:20
  • 3
    Hi @H2ONaCl .desktop files are special files, see my answer. – Jacob Vlijm Dec 7 '16 at 7:41

About .desktop files and their special function

.desktop files are special files. They represent applications in the GUI, either on your desktop or in Dash/Unity. To do so, a GUI -name of the application is set in a line inside the file in the line


You can simply change the name of how the application shows in Dash and Unity, by changing this line inside the .desktop file, without changing the file name of the .desktop file. In that case, it is irrelevant if the file is executable or not.

If the .desktop file is on your desktop however, if it is not executable, it does not work as a launcher, for reasons explained in souravac's answer, and "shows" under its own (file) name:


If it is executable and on your desktop, it works as a launcher and so it is is representing an application. Then it shows the application's name, as set in the line Name=

Language specific name

If the .desktop file has the line:


the file even shows a language- specific name, fetched from a language file, which will then show in Dash and Unity.

below a complicated example: filename = inkskape.desktop, "basic" interface name = Inkskape, translated name = Inkskape Vector Graphics Editor

enter image description here

The ls command

In the ls command is purely cli- based and always shows the file -name.

  • It seems useful for .desktop files to be special when they are on the ~/Desktop. It seems strange to me that they are special when they are at ~/.local/share/applications. – H2ONaCl Dec 7 '16 at 8:06
  • @H2ONaCl True, they do not need to be executable there, also not in /usr/share/applications most of the are not executable there and show their own name. Just look inside the directory. Dash/Unity reads their Name= -line then. – Jacob Vlijm Dec 7 '16 at 8:22
  • They do need to be executable anywhere under user's home directory. See screenshot from my desktop: imgur.com/a/bTXYj Without executable permissions set, it is not runable. Desktop is just a special case of a nautilus window, but same rules apply – Sergiy Kolodyazhnyy Dec 7 '16 at 9:31
  • @JacobVlijm I was responding to H2ONaCl about the files being special. I've no problem with your answer – Sergiy Kolodyazhnyy Dec 7 '16 at 9:40
  • @JacobVlijm I forget to do that sometimes – Sergiy Kolodyazhnyy Dec 7 '16 at 9:43

Quoting from Ubuntu's security policy:

Execute-Permission Bit Required

  • Applications, including desktops and shells, must not run executable code from files when they are both:

    • lacking the executable bit
    • located in a user's home directory or temporary directory.
  • This includes *.desktop, *.jar, and *.exe files.

What is a valid .desktop file under user's home directory?

According to Ubuntu's security policy the execution permission in .desktops files and shells script is a must to run executable code from those files when they are located in a user's home directory.

Nautilus will not consider a .desktop file as valid application shortcuts unless it has executable bit when they are located in a user's home directory.

On the other hand it is hard coded in nautilus's source code that it will show a valid .desktop file's name from the Name= or Name[$LANG] field inside the .desktop file ignoring the filename and extension. This does not apply to .sh or .jar files in nautilus.

Example: On a fresh Ubuntu installation every user gets examples.desktop in their home directory. The file name is examples.desktop. But in nautilus one can see it as Examples. If you look inside the .desktop file you can see following (I am showing only part of it):


You can check the permission (try ls -la /path/to/filename.extension) of Eclipse.desktop and smartgit.desktop. The former has executable bit set whereas the later has not.

That is why nautilus is recognizing Eclipse.desktop as application shortcuts and not showing its extension.

  • 1
    Yep, exactly that. Good job for providing the link as well. Good answer – Sergiy Kolodyazhnyy Dec 7 '16 at 6:49
  • I have many executables under ~/Documents/bashscripts which are "under" the home directory and yet Nautilus shows the file name extension of my *.sh files. This is true in list view and icon view. I have also copied java to the file x.x. Copying java to the file x.x keeps the executable permission of the original java file. Nautilus shows the file name to be x.x in both list view and icon view. What you say about executables does not seem to apply in these cases so in general it seems wrong to say that the executable bit causes the extension to be truncated from Nautilus. – H2ONaCl Dec 7 '16 at 7:04
  • 1
    The quote you cited seems to have nothing to do with file name truncation in Nautilus. It seems to describe the necessity of the execute bit. – H2ONaCl Dec 7 '16 at 8:59
  • 2
    @H2ONaCl it does have to do with filename truncation. Once a .desktop file is executable, the Name of application set inside the file can be set. Say you can have myapp.desktop and it has Name=Some Cool App line. With executable permission set, only then filename can be displayed as Some Cool App. Of course, the file must be in proper format,too, and actually have that Name= line. By the way , see souravc's edited answer, it was updated. – Sergiy Kolodyazhnyy Dec 7 '16 at 9:39
  • 1
    @H2ONaCl see also askubuntu.com/q/419610/295286 Related. – Sergiy Kolodyazhnyy Dec 7 '16 at 9:44

If a .desktop file is executable then Nautilus will recognize it as a desktop shortcut and will not display the name of the file, but rather the string set as the value of the Name= property in the file.

  • This may be true but for me it is unexpected when Nautilus is displaying files in ~/.local/share/applications/. Copying this file to ~/anyDirectory/ still results in a truncated file name. Neither of these places is the ~/Desktop. – H2ONaCl Dec 7 '16 at 8:14
  • 1
    Doesn't have to be in the ~/Desktop folder. The file name is not truncated. It's not displayed at all. Nautilus shows the Name= property set in the file. – AlexP Dec 7 '16 at 8:16
  • Ok, it's not truncated. It only looks that way by coincidence and it really came from inside the file. Why do we need this behavior at all when the authors of the 'ls' command did not see fit to do likewise. – H2ONaCl Dec 7 '16 at 8:56
  • @H2ONaCl Why would it be? The original ls command was written before GUIs were even "a thing", and there's no reason for a power-user program to treat one type of file completely differently from all of the others in an environment where the files in question aren't even used. – wizzwizz4 Dec 8 '16 at 8:09

At this link author "fragos" writes:

Unfortunately, if you open that folder in nautilus the .desktop files appears with the icon specified in the file and with the file name called out within the file.

When he says "file name called out within" he means the displayed file name is taken from within. I would say "file name called out within when the executable bit is set". He may be right that this is unfortunate. Strangely I have some that have the execute bit set and some that do not. The ones that do NOT have the execute bit set are not a cause of misfortune but I don't know why I was lucky. When the bit is set perhaps it can be considered a quirk or bug.

  • Developers can set the .desktop file executable or not. Most of them do not, as you can see in /usr/share/applications. There also is no reason to set them executable in there, and they will show their file name in nautilus (not in Unity/Dash). The fact that they can be used as a direct launcher makes sense, and so the fact that they show their GUI name then, when made executable. – Jacob Vlijm Dec 7 '16 at 8:56
  • That is not nautilus- specific. It all makes completely sense and is definitely not a bug. As mentioned, the GUI name, as in Dash/Unity, of a .desktop file is flexibel, often even language specific. No bug, that's how it is designed. – Jacob Vlijm Dec 7 '16 at 8:59
  • I don't know why you say this makes sense. There is an inconsistency. Some of the files do not have the execute bit set. What purpose do they serve when the bit is not set? If the files that do NOT have the bit set are still functional (and display the full name) then what is the justification for displaying the string taken from inside the file? The point is to examine directories of files just like the 'ls' command. Using the string from inside the file deviates from the behavior of the 'ls' command. How can that deviation be justified? – H2ONaCl Dec 7 '16 at 9:21
  • The files inside /usr/share/applications are not meant as (direct) launchers from the GUI, only to serve the (GUI) interface of the OS, like Unity and Dash in this case. There is no reason for a developer to make the file executable if stored there, nor in ~.local/share/applications. You can call it a bug if you want, but totally harmless, since it is not meant to use directly, unless it is on e.g. your desktop. When used to serve as a representative of your application, A .desktop file is meant to behave as a chameleon, depending on your language etc. – Jacob Vlijm Dec 7 '16 at 9:32
  • @Jacob Vlijm, Thank you for suggesting I can call it a bug if I want. I will settle for calling it a quirk that Nautilus has adopted a behavior meant for Unity on the Desktop or Dash. – H2ONaCl Dec 7 '16 at 19:19

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.