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.
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.