Seriously, it maintains (among other things, yes) the mapping from filename extensions to the path of the binary that should be used to open them.
It's a map : extension -> path.
WhyTF does MIME have to get dragged into this? Why can't I just say "*.foo is opened with /usr/bin/foobalize"? Why must I suffer the agony of trawling the interwebs to find out that blartz.foo is actually a z-content-flavor/foobalized_v3?
(Yes, I understand why browsers need to start the lookup using a MIME type. I'm talking about everything else -- the galaxy of things that don't use HTTP).
And even once I've found the Magic MIME type, xdg-open still does whatever it wants, and there appears to be no way to troubleshoot it when it's being invoked by another application. Setting XDG_UTILS_DEBUG_LEVEL=999 simply prints out a list of which files its reading (I can get that from strace, thanks), with no step-by-step rundown of its decision process:
$ XDG_UTILS_DEBUG_LEVEL=999 xdg-open ftp://foo.com
Selected DE generic
Checking /home/user/.config/mimeapps.list
Checking /home/user/.local/share/applications/defaults.list and /home/user/.local/share/applications/mimeinfo.cache
Checking /home/user/.local/share/applications/defaults.list and /home/user/.local/share/applications/mimeinfo.cache
Checking /usr/local/share//applications/defaults.list and /usr/local/share//applications/mimeinfo.cache
Checking /usr/local/share//applications/defaults.list and /usr/local/share//applications/mimeinfo.cache
Checking /usr/share//applications/defaults.list and /usr/share//applications/mimeinfo.cache
Checking /usr/share//applications/defaults.list and /usr/share//applications/mimeinfo.cache
Okay, y'all can downvote me now, ranty time is over.
No, xdg-utils are absolutely terrible. They're a mess of untested, undebuggable, underdocumented and extremely user unfriendly shell scripts that need to die and be replaced with something that actually had some serious design thought put into it.
I've once had xdg-open be absolutely broken on my machine, scanning all of my $HOME because of a file with a space character in it [1]. Any attempt to use xdg-open would pin a CPU core for 100% while bash/find recursively traversed millions of files because of missing quote characters in a shell script. Truly the pinnacle of software engineering.
I wouldn't be surprised if serious security bugs lurked somewhere in it, exploitable by web pages attempting to open maliciously crafted protocol URLs.
Seriously, it maintains (among other things, yes) the mapping from filename extensions to the path of the binary that should be used to open them.
It's a map : extension -> path.
WhyTF does MIME have to get dragged into this? Why can't I just say "*.foo is opened with /usr/bin/foobalize"? Why must I suffer the agony of trawling the interwebs to find out that blartz.foo is actually a z-content-flavor/foobalized_v3? (Yes, I understand why browsers need to start the lookup using a MIME type. I'm talking about everything else -- the galaxy of things that don't use HTTP).
And even once I've found the Magic MIME type, xdg-open still does whatever it wants, and there appears to be no way to troubleshoot it when it's being invoked by another application. Setting XDG_UTILS_DEBUG_LEVEL=999 simply prints out a list of which files its reading (I can get that from strace, thanks), with no step-by-step rundown of its decision process:
Okay, y'all can downvote me now, ranty time is over.