blog

filetype automation.xhtml (6140B)

<article xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" class="h-entry">
<a href="/articles/filetype%20automation"><h1>(Semi-)Automatic opening of Files</h1></a>
<h2>The current status on major systems</h2>
<p>
	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 <em>guess</em> 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.<br />
	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.
</p>
<p>
	This would be alright if files weren't mostly <em>made</em> as a way to exchange data between different applications. Oups.<br />
	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, …<br />
	But we all know that there isn't a single software which is capable of doing all of this <em>right</em>, yet there is probably multiple applications on your system which are capable of using a PDF file, the only thing it cares about.
</p>
<p>
	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 <code>.jar</code> files in the archiver (which can still sometime choke on them unless renamed to <code>.zip</code>), …
</p>
<h3>XDG, GTK, …</h3>
<p>
	XDG (Cross-Desktop Group) wrote a standard to have <code>xdg-open</code> being the executable to open files and paths like <code>/usr/share/applications</code> for applications to, among other things, advertise their supported file formats (and URLs schemes).<br />
	Of course GTK (gnome toolkit) and probably others, do not seem to use <code>xdg-open</code> at all and instead does their own thing to pick applications by themselves.<br />
	Goodbye consistent behavior.<br />
	Goodbye easy system improvements.
</p>
<h2><code>mailcap</code></h2>
<p>
	This file format (<a href="http://tools.ietf.org/html/rfc1524">RFC 1524</a>, 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.<br />
	But it is basically stuck in the niche of terminal-based email clients like <code>mutt</code> because of it's assumptions and design around MIME types.<br />
	Operating Systems are also often providing incomplete and broken static <code>mailcap</code> files referring to applications which might not be installed/available.
</p>
<h2>Plan9 <code>plumb</code></h2>
<p>
	The Plan9 plumbing infrastructure (<a href="http://man.9front.org/1/plumb">plumb(1)</a>) 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.<br />
	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.
</p>
<p>
	The file format (<a href="http://man.9front.org/6/plumb">plumb(6)</a>) 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.
</p>
<h2>My current methods</h2>
<p>
	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
	<code>~/.local/bin/xdg-open</code>
	which you can get into
	<a href="https://hacktivis.me/git/dotfiles/file/.local/bin/xdg-open.html">my dotfiles</a>.
<p>
</p>
	But as previously noted, simply changing <code>xdg-open</code> 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 <code>/usr/share/applications</code> by adding it into <code>INSTALL_MASK</code> and I removed everything in <code>~/.local/share/applications</code> and made it read-only.<br />
	One should also remove <code>/usr/share/mime</code> but that makes GTK fall on it's face because it relies on it for displaying things like icons via gdk-pixbuf.<br />
	Bleh.
</p>
<p>
	This means like most other terminal-based people I tend to launch applications manually, sometimes with passing the path/URL directly.
	<br />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.
	<br />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.
</p>
<p>
	<a href="https://queer.hacktivis.me/objects/bbbf1518-2691-419a-afa3-eb31249908b5">Fediverse post for comments</a>
	published on 2021-08-22T18:54:45Z,
	last updated on 2021-08-22T18:54:45Z
</p>
</article>