The basics of /etc/mailcap
on Ubuntu (and Debian)
One of the things that is an issue for any GUI desktop and for many
general programs is keeping track of what program should be used
to view or otherwise handle a particular sort of file, like JPEGs,
PDFs, or .docx
files. On Ubuntu and Debian systems, this is handled
in part through the magic file /etc/mailcap
, which contains a bunch
of mappings from MIME types to what should handle them, with various
trimmings. You can also have a personal version of this file in your
home directory as ~/.mailcap
.
In the old days when we didn't know any better, installing and
removing programs probably edited /etc/mailcap
directly. These
days the file is automatically generated from various sources,
including from individual snippet files that are stored in
/usr/lib/mime/packages
. Various programs drop files in this
directory during package installation and then update-mime
is
magically run to rebuild /etc/mailcap
. One should not confuse
/usr/lib/mime/packages
with /usr/share/mime/packages
; the latter
has XML files that are used by the separate XDG MIME application
specification.
(As the update-mime manpage covers, it also uses the MimeType=
information found in .desktop
files in /usr/share/applications.)
As far as I know, the update-mime manpage is
the sole good source for information about the format of these
little snippets in /usr/lib/mime/packages and the eventual format
of mailcap entries. The format is arcane, with many options and
quite a lot of complex handling, and there is no central software
package for querying the mailcap data; for historical reasons,
everyone rolls their own, with things like the Python mailcap
module. Update-mime
and other parts of this come from the mime-support
package.
(For fun, there are multiple generations of mailcap standards. We
start with RFC 1524
from 1993, and then extend from there. On Ubuntu systems, the
mailcap
manpage
doesn't document all of the directives that update-mime
does, for
example.)
A single MIME type may have multiple mailcap entries once all of
the dust settles (plus the possibility of wildcard entries as well
as specific ones, for example a 'text/*' entry as well as a
'text/x-tex' one). For example, on our Ubuntu login servers, there
are no less than 7 /etc/mailcap
entries for text/x-tex, and 13
for image/png and image/jpeg. In theory people using /etc/mailcap
are supposed to narrow down these entries based on whether or not
they can be used in your current environment (some only work in an
X session, for example) and their listed priorities. In practice the
mailcap parsing code you're using probably doesn't support the full
range of complexity on a current Ubuntu or Debian system, partly
because features have been added to the format over time, and it
may simple pick either the first or the last mailcap entry that
matches.
The Freedesktop aka XDG specifications have their own set of MIME association tracking standards, in the Shared MIME database specification and the MIME applications associations specification. These are used by, among other things, the xdg-utils collection of programs, which is how at least some GUI programs decide to handle files. I believe that these tools don't look at /etc/mailcap at all, but they do use MIME type information from .desktop files in /usr/share/applications and the XML files in /usr/share/mime/packages. They might even interpret it in the same way that update-mime does. The XDG tools and MIME associations all assume that you're using a GUI; they have no support for separate handling of a text mode environment.
Any particular GUI program might rely on the XDG tools, use mailcap, or perhaps both, trying XDG and then falling back on mailcap (parsed with either its own code or some library). A text mode program must use mailcap. I'm not sure how self-contained environments like Firefox and Thunderbird work, much less Chrome.
(See also the Arch Wiki page on default applications.)
|
|