To guess the filetype, most user environments rely on the file extension, a cue largely made by humans for humans.
This isn't much of a problem to automate from this, there is conventions and they are rarely broken.
They might also try to read the beginning of the file to guess it's filetype from it's first bytes, which isn't much better as it relies on formats having unambigious signature/magic headers, of course if you consider the chaos of file formats out there it often doesn't works.
The broken part is how the automation is designed, rather than having a system default and lettting the user nicely tweak it, it's mostly done towards applications advertising what they should be able to open and a rather obscure algorithm trying to pick one among the stack.
This would be alright if files weren't mostly made as a way to exchange data between different applications. Oups.
Let's pick a PDF file for example, even as one of the most write-once thing out there, you can do multiple kind of actions with it: reading, filling, editing, printing, transforming, reviewing, …
But we all know that there isn't a single software which is capable of doing all of this right, yet there is probably multiple applications on your system which are capable of using a PDF file, the only thing it cares about.
Of course in a great user-experience disaster, the users are encouraged to blindly trust the system to guess which application to use for a file.
Which of course is also often done in the bane of any reasonable security.
In my experience it tends to pick the most comically wrong application as default:
PDF files with The GIMP or LibreOffice, pictures with the web browser, text files into (Wine) Internet Explorer, Java .jar files in the archiver (which can still sometime choke on them unless renamed to .zip), …
XDG (Cross-Desktop Group) wrote a standard to have xdg-open being the executable to open files and paths like /usr/share/applications for applications to, among other things, advertise their supported file formats (and URLs schemes).
Of course GTK (gnome toolkit) and probably others, do not seem to use xdg-open at all and instead does their own thing to pick applications by themselves.
Goodbye consistent behavior.
Goodbye easy system improvements.
mailcap
This file format (RFC 1524, September 1993), mostly forgotten by anything graphical, goes a little bit into the right direction by being user-reviewable and modifiable. As well as allowing more metadata, finally there is a difference between viewing (default), composing, editing, printing.
But it is basically stuck in the niche of terminal-based email clients like mutt because of it's assumptions and design around MIME types.
Operating Systems are also often providing incomplete and broken static mailcap files referring to applications which might not be installed/available.
plumb
The Plan9 plumbing infrastructure (plumb(1)) is quite my preferred method to automate the opening of files and URLs (what are URLs if not mostly a protocol-aware file path).
It works based on what is basically a routing table to match against simple types (text, directory, …) and patterns on the path/url.
This is much more precise than the alternatives and will not lead to surprises on it's behavior as decisions are almost entirely made on user-known data.
The file format (plumb(6)) used to set it up is relatively simple but as it is about automation it is still a reduced programming language, as Plan9 is a spiritual successor to Unix it is textual but graphical environments wanting to clone it surely could also have a relatively simple setting window to match actions against rules.
Sadly I do not really use Plan9 (or rather 9front), I'm mostly stuck on Linux, where Plan9 design doesn't really integrates well.
So I maintain a shell script which like plumb matches against the file/URL, I stash it into
~/.local/bin/xdg-open
which you can get into
my dotfiles.
But as previously noted, simply changing
xdg-open doesn't works for every software.
So to at least calm down the forces of chaos I told my system's package manager, portage (gentoo default one), to not install any files into /usr/share/applications by adding it into INSTALL_MASK and I removed everything in ~/.local/share/applications and made it read-only./usr/share/mime but that makes GTK fall on it's face because it relies on it for displaying things like icons via gdk-pixbuf.
This means like most other terminal-based people I tend to launch applications manually, sometimes with passing the path/URL directly.
For other kind of people I would recommend putting icons of your frequent applications into your taskbar and others in folders and drag-dropping the files you want to open on their icons, this should be supported by most desktops.
For graphical things which aren't desktops well… there often isn't a decent file manager anyway so you're probably launching applications first all the time.
Fediverse post for comments published on 2021-08-22T18:54:45Z, last updated on 2021-08-22T18:54:45Z