The last step of my laptop migration was to fix mime type associations, that seem to associate opening file depending on whatever application was installed last, phases of the moon, and what option is the most annoying.
The state of my system after a fresh install, is that, for
xdg-open (used for example by pcmanfm) runs inkscape, and
for example by neomutt) runs the calibre ebook viewer.
It looks like there are at least two systems to understand, debug and fix, instead of one.
This comes from package
xdg-utils, and works using
# This runs inkscape $ xdg-open file.pdf
There is a tool called
xdg-mime that queries what
.desktop file is
associated with a given mime type:
$ xdg-mime query default application/pdf inkscape.desktop
You can use
xdg-mime default to change an association, and it works nicely:
$ xdg-mime default org.gnome.Evince.desktop application/pdf $ xdg-mime query default application/pdf org.gnome.Evince.desktop
However, if you accidentally mistype the name of the
.desktop file, it won't
complain and it will silently reset the association to the arbitrary default:
$ xdg-mime default org.gnome.Evince.desktop application/pdf $ xdg-mime query default application/pdf org.gnome.Evince.desktop $ xdg-mime default evince.desktop application/pdf $ echo $? 0 $ xdg-mime query default application/pdf inkscape.desktop
You can use a GUI like
xfce4-mime-settings from the
to perform the same kind of changes avoiding typing mistakes.
The associations seem to be saved in
This comes from the package mime-support
You can test things by running it using
$ run-mailcap --norun file.pdf ebook-viewer file.pdf
run-mailcap uses the
/etc/mailcap to map mime types to
commands. This is what's in the system default:
$ grep application/pdf /etc/mailcap application/pdf; ebook-viewer %s; test=test -n "$DISPLAY" application/pdf; calibre %s; test=test -n "$DISPLAY" application/pdf; gimp-2.10 %s; test=test -n "$DISPLAY" application/pdf; evince %s; test=test -n "$DISPLAY"
To fix this, I copypasted the evince line into
~/.mailcap, and indeed it gets
$ run-mailcap --norun file.pdf evince file.pdf
There is a
/etc/mailcap.order file providing a limited way to order entries
/etc/mailcap, but it can only be manipulated system-wide, and cannot be
used for user preferences.
Sadly, this means that if a package changes its mailcap invocation because of, say, a security issue in the former one, the local override will never get fixed.
I am really not comfortable about that. As a workaround, I put this in my
application/pdf; xdg-open %s && sleep 0.3s; test=test -n "$DISPLAY"; nametemplate=%s.pdf
sleep 0.3s is needed because
xdg-open exits right after starting the
program, and when invoked by mutt it means that mutt could delete the
attachment before evince has a chance to open it. I had to use the same
sensible-browser, since the same happens when a browser opens
a document in an existing tab. I feel like writing some wrapper about all this
that forks the viewer, then waits for an
IN_OPEN event on its argument via
inotify before exiting.
I wonder if there is any reason
run-mailcap could not be implemented as a
I reported #964723 elaborating on these thoughts.
nametemplate to the example, thanks François Marier