How does Linux choose which application to open a file?

Question

If a file tells the OS its file format, how does the OS choose which application to open it by default?

In Windows, is the association stored in the registry table?

How does Linux choose which application to open a file?

I used to use Nautilus a lot, but now I change to terminal. Is it true that in terminal, we always have to explicitly specify which application to open a file? Does the settings of which application to open a file of a certain format by default belong to the file manager (e.g. Nautilus), and it is not an issue when we are living in terminals?

Solution 1

There may be different mechanisms to handle these default settings. However, other answers tend to focus on complete desktop environments, each of them with its own mechanism. Yet, these are not always installed on a system (I use OpenBox a lot), and in this case, tools such as xdg-open may be used.

Quoting the Arch Wiki:

xdg-open is a desktop-independent tool for configuring the default applications of a user. Many applications invoke the xdg-open command internally.

At this moment, I am using Ubuntu (12.04) and xdg-open is available. However, when you use a complete desktop environment such as GNOME, xdg-open acts as a simple forwarder, and relays the file requests to your DE, which is then free to handle it as it wants (see other answers for GNOME and Nautilus, for instance).

Inside a desktop environment (e.g. GNOME, KDE, or Xfce), xdg-open simply passes the arguments to that desktop environment's file-opener application (gvfs-open, kde-open, or exo-open, respectively), which means that the associations are left up to the desktop environment.

... which brings you back to the other answers in that case. Still, since this is Unix & Linux, and not Ask Ubuntu:

When no desktop environment is detected (for example when one runs a standalone window manager, e.g. Openbox), xdg-open will use its own configuration files.

All in all:

                            |-- no desktop env. > handle directly.
User Request > xdg-open > --|
                            |-- desktop env.    > pass information to the DE.

If the first case, you'll need to configure xdg-open directly, using the xdg-mime command (which will also allow you to see which application is supposed to handle which file). In the second case...

                        |-- GNOME? > gvfs-open handles the request.
                        |
Info. from xdg-open > --|-- KDE?   > kde-open handles the request.
                        |
                        |-- XFCE?  > exo-open handles the request.

... you'll need to configure the file-opener associated with your desktop environment. In some cases, configuration made through xdg-mime may be redirected to the proper configuration tool in your environment.

Solution 2

From the wiki entry,

Linux-based GUIs, such as KDE and GNOME, support MIME type-based associations. For example, the MIME type text/plain would be associated with a text editor.

Also, this answer has more details.

File manager often use some combination of option a and b (e.g. look at the file extension first, if it's not known (or the file does not have an extension), look at the contents).

A file's type is not stored as metadata on common linux file systems.

From this answer, I see the below information.

The file manager (Nautilus, by default) uses the MIME type of a file to determine which program to open it with. When an application is installed, it can specify what MIME types it can open and the command to use to open the files in the .desktop file which is placed in /usr/share/applications. This is the file used for menus, desktop shortcuts, etc.

Solution 3

A file doesn't tell the OS its file format, with one exception:

If an executable file starts with a so-called shebang line, like

#! /usr/bin/perl

then this line tells the Linux kernel that it should be started with /usr/bin/perl (that is, instead of executing this file, it should execute usr/bin/perl and give this file as argument). This of course only works with file formats which ignore (or understand) such a shebang line.

Other than that, the operating system as such knows nothing about file types. However many programs which allow opening other files have their own mechanism to decide which program to use for opening which file. That can be a list inside the program itself (Firefox for example maintains such a list), or the program can delegate it to the desktop environment (of which there are several for Linux).

Usually, those mechanisms only consider the filename to decide what type the file is; an exception are email clients and web browsers, where usually the type of the file is explicitly given by the server/stated in the mail.

The mechanism is usually two-step:

• First, from the file name or supplied information, determine the MIME type of the file (the MIME type is a standardized, but extensible list of file types).
• Second, from the MIME type, determine which program to execute, usually through a sort of registry maintained either by the program itself or by the desktop environment the program was written for.

Solution 4

It is done similar to MS-Windows.

It is not done by OS. It is done by file manager, a part of the windowing system. Usually the part of the file-name after the last dot . is used to make the decision. There is a way to set them in settings, or when you right click on a file.

So the file does not tell the OS, the file is not active so can do nothing on its own, but the file manager looks at the file-name, the file manager could also look inside the file much as the file utility does.

Solution 5

I will attempt to give an underlying answer as to how Unix systems handle files. As others have pointed, your phrasing of the question is misleading since the files themselves do not report what type they are and the kernel itself doesn't decide which applications to use.

In Unix and Windows operating systems, files are structured simply as a sequence of bytes. From Tanenbaum's Operating Systems, third edition:

In effect, the operating system does not know or care what is in the file. All it sees are bytes. Any meaning must be imposed by user-level programs.

This is why, in a desktop environment, xdg-open is used to determine default applications for opening specific files types.

On a Unix system, files are differentiated between regular files and special files. A regular file is merely user data which may be either a text file (ASCII or Unicode encoding) or binary (executable code). Special files are files which are essential for running the OS. These include directories, links, pipes, sockets, and device files. ¹

It is by convention that file names contain extensions to indicate what type of file they may be e.g. *.c for C source code, *.html for web pages, etc. From Tanenbaum:

In some systems (e.g., UNIX), file extensions are just conventions and are not enforced by the operating system. A file named file.txt might be some kind of text file, but that name is more to remind the owner than to convey any actual information to the computer. On the other hand, a C compiler may actually insist that files it is to compile end in .c, and it may refuse to compile them if they do not.

If a file is saved or renamed without the proper extension, it still retains the same format for that file type. This is how most file managers decide what applications to open files with, and why without the extension most will prompt the user with "Choose the program you want to use to open this file:".

Lastly, environment variables are used to define system-wide and user-level settings. For example, the variable EDITOR is used to specify which text editor to open when handling text e.g. vim, nano, etc. This is how processes know which editor to open, like when editing a git commit message. Otherwise, you are correct that you must specify which application to use. Note that vim detects file types by checking extensions and inspecting file contents, if the setting filetype on is set, which then applies the correct syntax highlighting, indentation, etc. ²

TL;DR

In summary, it is the user-level applications which determine which programs to open a specific file type with, and not the OS itself.

View more solutions

Comments

[Stéphane Chazelas]

Linux is just the OS kernel. I suppose you mean your desktop environment or your file manager here. That's probably going to be different on Android, ChromeOS, Linux (or non-Linux) bases OSes running KDE, Gnome, XFCE... or other)

[Tim]

probably. I don't know which does the job. I am using gnome, but also would like to know about general.

[Stéphane Chazelas]

Then clarify the OS and Desktop environment and application. Like nautilus in Ubuntu 12.04 with "unity" desktop.

[Tim]

(1) I am under Ubuntu 12.04. Is my desktop Gnome or "Unity"? (2) I used to use Nautilus a lot, but now I change to terminal. Is it true that in terminal, we always have to explicitly specify which application to open a file? Does the settings of which application to open a file of a certain format by default belong to the file manager (e.g. Nautilus), and it is not an issue when we are living in terminals?

[reinierpost]

Shebang interpretation is a kernel function.

[Rob C]

@reinierpost True, but that only applies to scripts. Most other file formats don't start with a #! line. If you were to define a new file format, you could of course decide that it is going to start with a #! line, even if it is not intended for scripts. I'm not aware of any non-script file-format, that starts with a #! line.

[reinierpost]

@kasperd True. I must admit I was a little confused by the question here. I think the right answer to it is simply yes.

[Tim]

My question is "given the format type of a file", determines which application to open the file.

[Tim]

thanks. Is it true that in terminal, we always have to explicitly specify which application to open a file (except script with shebang)? Does the settings of which application to open a file of a certain format by default belong to the file manager (e.g. Nautilus), while it is not an issue when we are living in terminals?

[elpie89]

In an ideal world, Gnome and KDE would use xdg settings to choose which app to open a file, and would provide UIs to change xdg options. Then we could have just one settings database, instead of one for each DE. Alas xdg appeared too late.

[ctrl-alt-delor]

What you say about executables it true for all executables, not just #! files. But for executables there is meta information on the file system, the x bit has to be set.

[Amir]

Correction: the shebang line is not a message to the kernel; it's a message to the shell.

[celtschk]

@Kazark: coderwall.com/p/pdg77q

[celtschk]

Since the link to actual code in that linked page doesn't seem to work now, here's another link to the kernel code handling shebang lines: lxr.free-electrons.com/source/fs/binfmt_script.c — of course you could also just install the kernel sources yourself and look into the file.

[Ruslan]

Arguably, in Windows it's not done by file manager per se. Any application can call shell32!ShellExecute(), and although shell32 is part of Windows Shell, it's not part of Windows Explorer, which is the default file manager.

[Ruslan]

Some file managers analyze file content before filename extension (maybe they even always ignore the extension, not sure). E.g. in KDE's Dolphin if you have GIF images associated with a browser and PNG with image viewer, renaming file.png PNG file to file.gif will still open the image viewer. And if you empty the file, it'll open in text editor.

[Scott - Слава Україні]

@richard: I'm not sure what you mean by "there is meta information on the file system". The appropriate x bit needs to be set on a script before the shebang is effective; this is not a difference.

[Russell Borogove]

In an ideal world, you wouldn't have three DEs.

[ctrl-alt-delor]

@scott Meta information is information that is not in the file: name, size, permission bits, etc. In this case it is the x bit. And yes as you say it is not different, as I said “What you say about executables is true for all executables, not just #! files.”

[celtschk]

@richard: But the x bit is a permission bit. It says nothing about the file type, but only about the permission to execute. There can be a perfectly fine executable which you don't have permission to execute (while others may have the permission).

[ctrl-alt-delor]

@celtschk Are you unhappy that I include permissions, as meta data?

[celtschk]

@richard: The problem is not that it is metadata. The problem is that it is unrelated metadata. The OS uses the execute bit to determine if it tries to run the file, not how it tries to run it. But the latter is the topic of the question. An extended attribute storing a MIME type, or directly the executable to use, would also be meta data, but directly relevant to the question. The execute bit isn't.

[don_crissti]

@RussellBorogove - then we should all move to Windows. It's an ideal world.

[yorkshiredev]

@don_crissti I think this was more meant as "ideal for a developer or administrator". While it is a great thing to offer variety to an end user, it would indeed be a lot easier (yet not necessarily "better") for designers to focus on a single system. xdg-open is just one of these components which try to bring both ends together.

[don_crissti]

@John - about admins & various apps devs/designers: agreed... but then, upstream devs can only do so much. In an ideal world, instead of complaining about this or that, we would all contribute to upstream projects like KDE, Gnome etc to improve usability and iteroperativity between DEs. If all of us (millions) made just a small effort, all these issues would be solved in a few days.