Default applications

Programs implement default application associations in different ways. While command-line programs traditionally use environment variables, graphical applications tend to use XDG MIME Applications through either the GIO API, the Qt API, or by executing /usr/bin/xdg-open, which is part of xdg-utils. Because xdg-open and XDG MIME Applications are quite complex, various alternative resource openers were developed. The following table lists example applications for each method.

MethodUses XDGApplication examples
GIO's GAppInfoYesFirefox, GNOME Files, PCManFM, Thunar, Thunderbird, Telegram
/usr/bin/xdg-openBy defaultChromium (Open downloaded file)
CustomUsually notmc, ranger
Environment variablesNoman, sudoedit, systemctl
D-Bus's FileManager1org.freedesktop.FileManager1Firefox (Open containing folder), Zotero (Show file), Telegram (Show in folder)

Many desktop environments and graphical file managers provide a GUI for configuring default applications.

Background information

Programs sometimes need to open a file or a URI in the user's preferred application. To open a file in the user's preferred application the filetype needs to be detected (usually using filename extensions or magic numbers mapped to MIME types) and there needs to be an application associated with the filetype.

Heirloom UNIX programs used mime.types for MIME type detection and mailcap for application association.

Resource openers

  • XDG MIME Apps: implements the XDG MIME Applications specification
  • RegEx rules: allows MIME types to be associated with applications using regular expressions
  • URI support: allows arbitrary URI schemes to be associated with applications
NamePackageXDG MIME AppsRegEx rulesURI support
xdg-openxdg-utilsYesNoYes
mimeopen(1p)perl-file-mimeinfoYesNoNo
mimeomimeoAURYesYesYes
linopenlinopenAURNoYesYes
mimimimi-gitAURNoNopartly
buskingbusking-gitAURNoYesYes
rangerNoYesNo
handlrYesNoYes
clifmNoYespartly
mimejs-gitNoNoYes

xdg-open

xdg-open (part of xdg-utils) implements XDG MIME Applications and is used by many programs.

Because of the complexity of the xdg-utils version of xdg-open, it can be difficult to debug when the wrong default application is being opened. Because of this, there are many alternatives that attempt to improve upon it. Several of these alternatives replace the /usr/bin/xdg-open executable, thus changing the default application behavior of most applications. Others simply provide an alternative method of choosing default applications.

perl-file-mimeinfo

perl-file-mimeinfo provides the tools mimeopen(1p) and mimetype(1p). These have a slightly nicer interface than their equivalents:

# determine a file's MIME type
$ mimetype photo.jpeg
photo.jpeg: image/jpeg

# choose the default application for this file
$ mimeopen -d photo.jpeg
Please choose an application

    1) Feh (feh)
    2) GNU Image Manipulation Program (gimp)
    3) Pinta (pinta)

use application #

# open a file with its default application
$ mimeopen -n photo.jpeg

Most importantly, xdg-utils programs will actually call instead of mimetype for MIME type detection if it does not detect your desktop environment. This is important because does not follow the XDG standard.

mimeo

provides the tool , which unifies the functionality of  and .
# determine a file's MIME type
$ mimeo -m photo.jpeg
photo.jpeg
  image/jpeg

# choose the default application for this MIME type
$ mimeo --add image/jpeg feh.desktop

# open a file with its default application
$ mimeo photo.jpeg

However a big difference with xdg-utils is that mimeo also supports custom "association files" that allow for more complex associations. For example, passing specific command line arguments based on a regular expression match:

# open youtube links in VLC without opening a new instance
vlc --one-instance --playlist-enqueue %U
  ^https?://(www.)?youtube.com/watch\?.*v=
patches xdg-utils so that  falls back to mimeo if no desktop environment is detected.

handlr

, written in Rust, provides the functionality of and with a streamlined interface.

Compared to , it includes:

  • setting associations by extension, removing the need to look up or remember mime types
  • validation for mime types and extensions
  • removal of invalid entries from mimeapps.list
  • intelligent detection of mime types from file content in case filename is ambiguous
  • autocompletion of mimes, extensions, and desktop entries
# The following two are identical
handlr set .png feh.desktop
handlr set image/png feh.desktop

# List default apps
handlr list

# Get the handler for a mime/extension
$ handlr get .png --json
{"handler":"pqiv.desktop","name":"pqiv","cmd":"/usr/bin/pqiv"}

# Launch a handler with optional path/URL
handlr launch x-scheme-handler/https
handlr launch x-scheme-handler/https -- https://google.ca
provides an  that uses  under the hood to replace .

clifm

Lira, 's built-in resource opener, can be used as a standalone resource opener via the command line option. The configuration file (~/.config/clifm/profiles/PROFILE_NAME/mimelist.cfm) supports regular expressions for both MIME types and file names (or file extensions). A few examples:

# Open a regular file
clifm --open /etc/hosts

# Open a directory
clifm --open /media/data

# Open an URL (via the application associated to the text/http MIME type in the configuration file)
clifm --open www.archlinux.org

Minimalist replacements

The following packages conflict with and provide because they provide their own /usr/bin/xdg-open script.

If you want to use one of these resource openers while still being able to use , install them manually in a PATH directory before .

  • linopenAUR - 170-line Bash script, supports regex rules
  • mimi-gitAUR - 130-line Bash script, can change command arguments for each MIME type
  • busking-gitAUR - 80-line Perl script similar to mimi but also supports regex rules
gollark: I think that if the price does go massively higher, people will just talk about how important it is and how everyone needs an education and stuff, and it'll be subsidized somehow and/or you'll just have to take out giant loans, instead of just not doing college.
gollark: I'm reading through the backlogs here.
gollark: It's possible to brute-force encryption in theory, but modern crypto makes this very impractical to do given constraints like the available size of the universe and stuff.
gollark: <@!692654568827387986> I'm pretty sure you're wrong about encryption here. You can't just magically decrypt stuff without the key. Encrypted data you don't have the key for is indistinguishable from random noise.
gollark: It still has calls to Google stuff in it, they're just visibly there.
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.