August 1st, 2024

xdg-override: change default application temporarily on Linux

The xdg-override tool modifies xdg-open behavior in GNU/Linux, allowing temporary changes to default applications for files and URLs. Installation is easy, and the author welcomes suggestions for improvements.

Read original articleLink Icon
ConfusionFrustrationCuriosity
xdg-override: change default application temporarily on Linux

The GitHub repository xdg-override offers a tool designed to modify the behavior of xdg-open, which is used in GNU/Linux systems to open files and URLs with preferred applications. This tool enables users to temporarily change the default application for opening files or URLs without modifying system settings. For example, users can configure links to open in a different browser for specific applications, such as using Chromium for URLs in Slack with the command `xdg-override --match "^https?://" chromium slack`.

Installation is straightforward for Nix users, who can run it directly from the flake or execute it without installation. Other users can download the script and place it in a desired location, as it does not require configuration. The tool includes command options such as `-h` for help and `-m <regex> <command>` to override handling of specific MIME types. An example command allows all YouTube URLs to open in mpv while other URLs open in Firefox when launching Thunderbird.

The author has indicated that no new features will be added but is open to issues and suggestions for improvements. For further details, users can visit the repository.

AI: What people are saying
The comments on the xdg-override tool reveal a mix of opinions and experiences regarding file opening behavior in GNU/Linux systems.
  • Several users have created their own scripts or tools to customize the behavior of xdg-open, indicating a desire for more control over file handling.
  • Some commenters express frustration with the existing xdg-open functionality, suggesting it can be confusing or inadequate for their needs.
  • There is a discussion about the appropriateness of modifying the PATH environment variable and the implications of such changes on application behavior.
  • Users share alternative solutions, such as using specific applications or scripts to handle file opening more effectively.
  • Some commenters question the necessity of the xdg-override tool, suggesting that existing methods suffice for their use cases.
Link Icon 10 comments
By @arp242 - 6 months
I just have a small shell script as "xdg-open". Writing this was easier than figuring out the magic xdg-* tools use the figure out the default application for something, and then not having that work on random days for reasons of planetary alignments.

This is not that different from "xdg-override"; you can add global overrides for specific URLs with a simple match, and matches from a specific application by checking the parent process (e.g. $(readlink /proc/$PPID/exe) = /usr/bin/slack, or some such). It seems easier to me to have everything in one place.

I also considered popping up dmenu for unknown filetypes, but I don't use it that much and don't really need it.

At any rate, "to whom it might be useful":

  #!/bin/zsh
  #
  # xdg-open, without suckage.
  [ "${ZSH_VERSION:-}" = "" ] && echo >&2 "Only works with zsh" && exit 1
  setopt err_exit no_unset pipefail
  
  (( $+1 )) || { print >&2 'need a parameter'; exit 1 }
  
  # Open URL.
  if [[ -z "${1:#*://*}" ]]; then
   proto=${(L)1%%://*}
   case $proto in
    (http|https)   exec firefox $1 ;;
    (file)      
     1=${1##$proto://} # Remove protocol
     1=/${1#*/}        # Remove hostname
    ;;
    (*)
     print >&2 "xdg-open: no URL handler for protocol '$proto://' (for: $1)"
     exit 1
   esac
  fi
  
  # Open file.
  ext=${(L)1:e}
  case $ext in
   (html|htm|pdf)                                  exec firefox   $1 ;;
   (png|webp|jpg|jpeg|heic)                        exec firefox   $1 ;;
   (mp?|ogg|flac|m4v|mkv|avi|mov|wav)              exec mpv       $1 ;;
   (md|markdown|txt|sh|zsh|go|py|rb|js|c|json|xml) exec st -e vim $1 ;;
   (*)
    mime=$(file -b --mime $1 2>&/dev/null ||:)
    t=${mime%/*}
    case $t in
     (text)        exec st -e vim $1 ;;
     (image)       exec firefox   $1 ;;
     (audio|video) exec mpv       $1 ;;
    esac
    print >&2 "xdg-open: don't know how to open '.$ext' files (mime: '$mime') (for: $1)"
    exit 1
  esac
By @sureglymop - 6 months
On gnome there is a GTK4 app called "Junction". It pops up a dialog that let's you choose what application to open the given content in. I highly recommend just aliasing 'open' to use that.

https://apps.gnome.org/Junction/

By @nrabulinski - 6 months
I don’t understand those comments. I’ve been using sway for years, i3 before that and I’ve been using xdg-open since forever to open any file in the default application and I never felt it was confusing or I that I needed to replace it with something else. What am I missing?
By @bandie91 - 6 months
IMO PATH-prepending is the right (unix-y) way to override certain commands, as OP does.

but sadly, many projects, programms which I came across (mostly but not exclusively daemons), defines PATH for themself, not respecting inheritence: saying "what if someone set it up maliciously" or "default PATH is not enough / too wide / in wrong order / etc" ...

man, sorry, process! what you inherit is what there is, it's your environment where you need to do your job. you can't? just fail and let the caller know the error case. will you (as an app author) change the CWD because it's unfamiliar (breaking relative path parameters along the way)? or redirect STDERR from a file to tty because "user MUST SEE this error" (making it NOT shown in the error log where the user did want to put the error output)? no. that's why you should not touch PATH. except if you are a logon process, a wrapper whose responsibility is to prepare the env for descendents, or crossing privilege boundary.

due to this defiance of many programms, I started to switch from PATH-prepending to "over-mount executables in separate mount namespace" strategy. I hope it won't be voided by they invent "let's switch to the default namespace because it's my will" type of overreach.

By @M95D - 6 months
> Override xdg-open behavior. Because the way it already works is not confusing enough.

Oh! YESSSSS!!! FINALLY!!! I've been removing x permissions for xdg-open for YEARS!!! I hope this works.

By @fossdd - 6 months
That reminds my of a own xdg-open I wrote that sits in /usr/local/bin/xdg-open.

It's a simple python script that checks by looking at the protocol, mime type or extension which URL it is and also asks if there are multiple applications

https://paste.sr.ht/~fossdd/7fa65e10998ebcc03a2bbcc8488f94e9... (CC0)

By @Kudos - 6 months
My work VPN client doesn't work in Firefox, so I hacked something much more specific together to deal with that problem

  #!/bin/sh
  
  if [ "$@" = "/tmp/gpauth.html" ]
  then
    flatpak run --filesystem=/tmp/gpauth.html org.chromium.Chromium /tmp/gpauth.html
  else
    /usr/bin/xdg-open "$@"
  fi
By @bandie91 - 6 months
joining to the "everyone reimplements a file-opener" team (shameless plug) : https://github.com/bAndie91/mimeopen-gui
By @ThrowawayTestr - 6 months
Is this like the "open with" option in Windows?
By @TZubiri - 6 months
Who would win customxdgoverridebinary application .ext

or just

application file.ext

Some people just really take any excuse to write a program.