Override xdg-open behavior with xdg-override

Most application on GNU/Linux by convention delegate to xdg-open when they need to open a file or a URL. This ensures consistent behavior between applications and desktop environments: URLs are always opened in our preferred browser, images are always opened in the same preferred viewer.

However, there are situations when this consistent behavior is not desired: for example, if we need to override default browser just for one application and only temporarily. This is where xdg-override helps: it replaces xdg-open with itself to alter the behavior without changing system settings.

↫ xdg-override GitHub page

I love this project ever since I came across it a few days ago. Not because I need it – I really don’t – but because of the story behind its creation. The author of the tool, Dmytro Kostiuchenko, wanted Slack, which he only uses for work, to only open his work browser – which is a different browser from his default browser. For example, imagine you normally use Firefox for everything, but for all your work-related things, you use Chrome. So, when you open a link sent to you in Slack by a colleague, you want that specific link to open in Chrome.

Well, this is not easily achieved in Linux. Applications on Linux tend to use freedesktop.org’s xdg-open for this, which looks at the file mimeapps.list to learn which application opens which file type or URL. To solve Kostiuchenko’s issue, changing the variable $XDG_CONFIG_HOME just for Slack to point xdg-open to a different configuration file doesn’t work, because the setting will be inherited by everything else spwaned from Slack itself. Changing mimeapps.list doesn’t work either, of course, since that would affect all other applications, too.

So, what’s the actual solution?

We’d like also not to change xdg-open implementation globally in our system: ideally, the change should only affect Slack, not all other apps. But foremost, diverging from upstream is very unpractical. However, in the spirit of this solution, we can introduce a proxy implementation of xdg-open, which we’ll “inject” into Slack by adding it to PATH.

↫ Dmytro Kostiuchenko

xdg-override takes this idea and runs with it:

It is based on the idea described above, but the script won’t generate proxy implementation. Instead, xdg-override will copy itself to /tmp/xdg-override-$USER/xdg-open and will set a few $XDG_OVERRIDE_* variables and the $PATH.

When xdg-override is invoked from this new location as xdg-open, it’ll operate in a different mode, parsing $XDG_OVERRIDE_MATCH and dispatching the call appropriately. I tested this script briefly, but automated tests are missing, so expect some rough edges and bugs.

↫ Dmytro Kostiuchenko

I don’t fully understand how it works, but I get the overall gist of what it’s doing. I think it’s quite clever, and solves a very specific issue in a non-destructive way. While it’s not something most people will ever need, it feels like something that if you do need it, it will quickly become a default part of your toolbox or workflow.