commit: 44f4b97b70d19ff2ae1934ed43ae09a8bbb5fff1
parent 85087925c2ccbdde1956095fc30db0379499a521
Author: Haelwenn (lanodan) Monnier <contact@hacktivis.me>
Date: Sun, 22 Aug 2021 18:54:45 +0200
Article: (Semi-)Automatic opening of Files
Diffstat:
4 files changed, 99 insertions(+), 0 deletions(-)
diff --git a/articles/filetype automation.shtml b/articles/filetype automation.shtml
@@ -0,0 +1,15 @@
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+<!--#include file="/templates/head.shtml" -->
+ <meta property="og:type" content="article"/>
+ <meta property="og:title" content="(Semi-)Automatic opening of Files"/>
+ <title>(Semi-)Automatic opening of Files — Cyber-home of lanodan</title>
+ </head>
+ <body>
+<!--#include file="/templates/en/nav.shtml" -->
+<!--#include file="/articles/filetype automation.xhtml"-->
+ <a href="/articles/filetype%20automation.xhtml">article only(plain XHTML)</a>
+<!--#include file="/templates/en/footer.shtml" -->
+ </body>
+</html>
diff --git a/articles/filetype automation.xhtml b/articles/filetype automation.xhtml
@@ -0,0 +1,72 @@
+<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>
diff --git a/feed.atom b/feed.atom
@@ -11,6 +11,17 @@
<!-- new.sh: new articles here -->
<entry>
+ <title>(Semi-)Automatic opening of Files</title>
+ <link rel="alternate" type="text/html" href="/articles/filetype%20automation"/>
+ <id>https://hacktivis.me/articles/filetype%20automation</id>
+ <published>2021-08-22T14:28:21Z</published>
+ <updated>2021-08-22T14:28:21Z</updated>
+ <content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<!--#include file="/articles/filetype automation.xhtml"-->
+ </div></content>
+ </entry>
+
+ <entry>
<title>BadWolf, two years later</title>
<link rel="alternate" type="text/html" href="/articles/BadWolf%2C%20two%20years%20later"/>
<id>https://hacktivis.me/articles/BadWolf%2C%20two%20years%20later</id>
diff --git a/home.shtml b/home.shtml
@@ -54,6 +54,7 @@
<li>2021-03-07: <a href="/articles/Why%20I%20embraced%20Wayland">Why I embraced Wayland</a></li>
<li>2021-04-07: <a href="/articles/self-hosting">self-hosting</a></li>
<li>2021-04-20: <a href="/articles/BadWolf%2C%20two%20years%20later">BadWolf, two years later</a></li>
+ <li>2021-08-22: <a href="/articles/filetype%20automation">(Semi-)Automatic opening of Files</a></li>
</ol>
</main>
<!--#include file="templates/en/footer.shtml" -->
