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
In a sense, xdg-open does exactly what your script does. Only it reads associations from mimeapps.list.
The complexity comes from the integration with various desktop environments. And this I understand. Ideally, everyone would use xdg-utils, but there's legacy, backward compatibility, what not.
What I don't understand is why those DE-specific openers do not always respect xdg settings. For instance, kde-open would respect mineapps.list for almost everything except default browser.
For me this is the main source of confusion and I would guess, this is the main driver behind numerous xdg-open alternatives out there.
xdg-open has the nice benefit that I can just right click a file in the file manager and select "Set default opener for file type". And then it's saved.
This is why I wanted to override xdg-open temporarily, instead of writing yet another complete replacement.
Plus, XDG is the de facto standard. Its implementation so far is not perfect, but I feel like aligning with the standard is better than diverging from it.
> The complexity comes from the integration with various desktop environments
Usually I'm the first one who defends open source solutions and blames complexity and compatibility... But xdg-open is just an awful interface to interactive with, probably my most hated Linux desktop cli tool.
I'd love to understand this better. My first reaction was too, that it's much more complex than it probably should be. OTOH, as I said, after reading through its code, it doesn't seem to do much more than many of its alternatives
1. it can be called with just a single argument
2. if it's running under a DE, it delegates to the ${de}-open. In the same fashion, it handles some esoteric cases, like flatpak and WSL2...
3. if it's not running under a DE or it's one of the esoteric cases, it parses $1 and reads associations from an INI file
4. finally if the executable is supplied in a form of desktop file, it resolves it to a command
Most of its alternatives do steps 1 and 3, and do not do steps 2 and 4. And it doesn't seem like too much incidental complexity tbh. Step 4 seems totally legit. Step 2 — controversial, but I can rationalize this with legacy and backward compatibility.
And even when we start thinking about all those ${de}-open... Probably those are needed for some eye candy, like jumping icons in the dock when an app is launching... IDK, I'm just speculating.
> In a sense, xdg-open does exactly what your script does.
Pretty much, yeah. It's just a simple mapping, right? I don't recall what problems I had exactly, but it was just a pain and stopped working at various points, or just didn't do what I wanted and couldn't get to behave as I wanted. So I spent half an hour six or seven years ago and that fixed it (I added the MIME support last year or so, another 15 minutes).
At some point of knowledge it's easier and less time-consuming to just script these things rather than relying on some generic system. It is for me anyway.
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":