Custom commands in Firefox with Tridactyl

2026-02-20T00:00:00+00:00

The scenario</a></h2>
You're on a web page and you want to extract some content from it and use it in an external command. Or a more specific use case, you use Miniflux</a> as your feed reader to follow some podcasts and you want to play those podcasts in MPD</a>. You use Firefox</a> as your browser together with Tridactyl</a> and Native Messaging</a>. mpc</a> will be used for controlling MPD.</p>

The audio part for a podcast is rendered as an <audio></code> element in Miniflux. An <audio></code> element looks something like this:</p>

<</span>audio</span> ...</span>></span></span>
    <</span>source</span> src</span>=</span>"https://example.com/sound.mp3"</span> ...</span>></span></span>
</</span>audio</span>></span></span></code></pre>
So to get the URL to the audio file, we select the src</code> attribute of the
<source></code> element. For our use case, we know that we'll only have one of these
elements, so we're happy with just getting the first one:</p>
js</span> document</span>.</span>querySelector</span>(</span>"source"</span>).</span>src</span></span></code></pre>
The output is then piped to the
shellescape</code></a>
method using the special variable JS_ARG</code>, which contains the result from the
previous command (shown on two lines for clarity):</p>
js</span> document</span>.</span>querySelector</span>(</span>"source"</span>).</span>src</span> |</span></span>
js</span> -</span>p</span> tri</span>.</span>excmds</span>.</span>shellescape</span>(</span>JS_ARG</span>)</span></span></code></pre>
The -p</code> flag is needed for JS_ARG</code> to work.</p>
Lastly, we call our external command with the escaped URL as an argument.
shellescape</code> returns a promise, so we need to handle that. We also need to
prefix everything with
composite</code></a>,
to make the pipe work. Combining everything and creating a new
command</a>,
this is the final line that goes into our ~/.tridactylrc</code> (or wherever you
keep it) file:</p>
command pod2mpd composite js</span> document</span>.</span>querySelector</span>(</span>"source"</span>).</span>src</span> |</span> js</span> -</span>p</span> tri</span>.</span>excmds</span>.</span>shellescape</span>(</span>JS_ARG</span>).</span>then</span>(</span>url</span> =></span> tri</span>.</span>excmds</span>.</span>exclaim_quiet</span>(</span>'mpc add '</span> +</span> url</span>))</span></span></code></pre>
Finally we bind a key sequence to the command:</p>
bind ,p pod2mpd</span></span></code></pre>
Now, pressing ,p</code> will find the first source element on the current page and
add its URL to MPD. This could, of course, be altered to instead send the link
to another media player, download the file, or call an external script for more
advanced handling (perhaps selecting multiple elements on the page, extracting
links and selecting among them using fzf</a>),
and so on. Lots of possibilities!</p>



How I Make
2025-04-17T00:00:00+00:00
For the last decade or so, I've had the privilege of working with colleagues
who have put up with (some of) my ideas on how to do things. One of those ideas
has been to use Makefiles</a> for building and doing other tasks. This post
suggests conventions to follow when dealing with web projects, both frontend
and backend, but it also applies to most other projects. The reason for trying
to follow a convention is that regardless of the project you end up with, you
should never wonder how to get it running, run tests, etc. (This is not
targeted at C-like languages and compilers, where using Make might be a more
obvious choice due to historical reasons and the way those languages are compiled.)</p>
But first:</p>
Why not scripts in package.json?</a></h2>
Defining tasks in a format that does not support newlines, comments,
dependencies between tasks, only does what is needed, etc., is a...peculiar
choice. Also, this approach would only work for projects using npm (or similar
tools).</p>
Rules</a></h2>
This is the rules I try to use. Most examples are using
npm</a>, Typescript</a>
and Parcel</a>, but it will work with any tools.</p>
build</code></a></h3>
This will do whatever is needed to create something that can be deployed.
Typical commands for a project using Parcel and Typescript include:</p>
.PHONY</span>:</span> build</span></span>
build</span>:</span> node_modules</span></span>
	node_modules/.bin/tsc --noEmit</span></span>
	node_modules/.bin/parcel build</span></span></code></pre>
node_modules</code> is a prerequisit, this makes it possible to just clone the
project and then run this rule, and everything should just work.</p>
This rule is the default target, i.e., it's enough to execute $ make</code> to run
it.</p>
run</code></a></h3>
This target will run the project.</p>
.PHONY</span>:</span> run</span></span>
run</span>:</span> node_modules</span></span>
	node_modules/.bin/parcel serve</span></span></code></pre>
For a frontend project without any build steps (or tools not having a server function),
serving via python's http module is an excellent alternative:</p>
.PHONY</span>:</span> run</span></span>
run</span>:</span></span>
	python -m http.server</span></span></code></pre>test</code></a></h3>
A target for running all the test cases for the project.</p>
lint</code></a></h3>
Next up is the lint</code> rule. This could either be a single rule that checks
everything that you care about, or include additional rules for other tools.
For example, in web projects, a good command nowadays covering both lint and
formatting using biome</a> would look like:</p>
.PHONY</span>:</span> lint</span></span>
lint</span>:</span> node_modules biome.json</span></span>
	node_modules/.bin/biome check src/</span></span></code></pre>
If you are using ESLint and Prettier (or something else), you might want to
have them in two separate rules, or run both in a single lint</code> rule. It
depends on whether you have the need to run them independently or not.</p>
ci</code></a></h3>
This is perhaps the most important rule (or really, all are important, but bear
with me...). This is the only</strong></em> rule that is allowed to run in a CI
workflow for checking the code (and possibly the commit message or other
checks). This rule usually doesn't have any commands, instead it has other
rules as prerequisites. Example:</p>
.PHONY</span>:</span> ci</span></span>
ci</span>:</span> lint build test</span></span></code></pre>
If you run $ make ci</code> before pushing to a CI workflow, you can be confident
that the CI job won't fail either (as long as you're running it on the same
code base). You should never have to open any CI configuration to figure out
what is running.</p>
node_modules</code></a></h3>
This is the only rule with a "real" target, i.e., the target is an actual
file/directory. The rule  makes sure node_modules</code> exists and is up to date.
Most other rules have this one as a prerequisite.</p>
node_modules</span>:</span> package.json package-lock.json</span></span>
        npm ci</span></span></code></pre>clean</code></a></h3>
If the build target generates any files, for example a dist</code> or build</code>
folder, have a clean</code> target for cleaning up:</p>
.PHONY</span>:</span> clean</span></span>
clean</span>:</span></span>
	rm -rf build/</span></span></code></pre>Bonus rules</a></h2>
The above is the standard that would be relevant for all projects. Besides
these, there may be more specific rules. For example, if the project depends on
a database, it would be helpful to define a target for running it:</p>
.PHONY</span>:</span> database</span></span>
database</span>:</span></span>
	docker ps | grep -q database || docker run --rm -p 127.0.0.1:27017:27017 --name database -d mongo --bind_ip_all</span></span></code></pre>
And then have this as a prerequisite for the run</code> rule.</p>
If the project is packaged as a Docker/Podman/other image, add targets for
building, tagging and publishing it. Similarly, if it's a npm package, add
targets for publishing it. Use these targets in the CI workflow.</p>
Conclusions</a></h2>
The takeaway from this isn't so much about which rules you should have, what
they are named, or what they do. Instead, the point is that it's worth striving
for consistency between projects, especially in a team (or across teams) using
multiple tools and programming languages. Another key takeaway is that if you
have a CI setup, whatever it runs should also be possible to run locally. By
running make ci</code> and then pushing to the CI tool, you should be able to assume
it will pass.</p>
Full example</a></h2>
Finally, here's a full example for a node project using typescript, ava</a>, mongodb</a>,
biome and docker:</p>
IMAGE</span> :=</span> company/project</span></span>
NAME</span> ?=</span> my_project</span></span>
BIOME_CONFIG</span> :=</span> node_modules/@company/configs/biome.json</span></span>
</span>
.PHONY</span>:</span> build</span></span>
build</span>:</span> node_modules</span></span>
	node_modules/.bin/tsc</span></span>
</span>
.PHONY</span>:</span> run</span></span>
run</span>:</span> node_modules database</span></span>
	node --import tsx src/index.ts</span></span>
</span>
.PHONY</span>:</span> database</span></span>
database</span>:</span></span>
	docker ps | grep -q database || docker run --rm -p 127.0.0.1:27017:27017 --name database -d mongo --bind_ip_all</span></span>
</span>
biome.json</span>:</span> $(</span>BIOME_CONFIG</span>)</span></span>
	ln -s $< $@</span></span>
</span>
.PHONY</span>:</span> lint</span></span>
lint</span>:</span> node_modules biome.json</span></span>
	node_modules/.bin/biome check src/ test/</span></span>
</span>
.PHONY</span>:</span> lint-fix</span></span>
lint-fix</span>:</span> node_modules biome.json</span></span>
	node_modules/.bin/biome check --write src/ test/</span></span>
</span>
node_modules</span>:</span> package.json package-lock.json</span></span>
	npm ci</span></span>
</span>
.PHONY</span>:</span> docker</span></span>
docker</span>:</span></span>
	docker build --progress=plain --pull -t </span>$(</span>IMAGE</span>)</span>:latest .</span></span>
</span>
.PHONY</span>:</span> docker-run</span></span>
docker-run</span>:</span></span>
	docker run -rm --name </span>$(</span>NAME</span>)</span> -it </span>$(</span>IMAGE</span>)</span>:latest</span></span>
</span>
.PHONY</span>:</span> test</span></span>
test</span>:</span> node_modules database</span></span>
	NODE_OPTIONS='--import=tsx' node_modules/.bin/ava test/test*</span></span>
</span>
.PHONY</span>:</span> ci</span></span>
ci</span>:</span> lint build test</span></span>
</span>
.PHONY</span>:</span> clean</span></span>
clean</span>:</span></span>
	rm -rf dist</span></span></code></pre>


WireGuard VPN in a network namespace
2024-08-22T00:00:00+00:00
The scenario</a></h2>
Say you want to run only a specific program via a VPN, but let the rest of your
system use the ordinary connection. For our example, we will use curl</code> as the
program that should use the VPN tunnel, and as VPN provider, we will use
Mullvad</a> and their
WireGuard</a> endpoints, but the setup should work
for any VPN provider using WireGuard.</p>
Before we start</a></h2>
To verify if we are connected via Mullvad or not, we can make calls to
https://am.i.mullvad.net/connected</a>.</p>
Let's see how it looks before we start:</p>
$ curl https://am.i.mullvad.net/connected</span></span>
You are not connected to Mullvad. Your IP address is 111.222.111.111</span></span></code></pre>
Great, just as expected we are not using the VPN tunnel.</p>
For setting everything up, we will use the wg</code> tool, part of the wireguard-tools</code> package. See
https://www.wireguard.com/install/</a> for installation instructions. We will also
need a config file, this can be generated on the Mullvad page</a> and will look
something like:</p>
[</span>Interface</span>]</span></span>
PrivateKey</span> = <</span>private key></span></span>
Address</span> = <</span>IPv4>/32,<IPv6>/128</span></span>
</span>
[</span>Peer</span>]</span></span>
PublicKey</span> = <</span>public key></span></span>
AllowedIPs</span> =</span> 0.0</span>.0.0/0,::0/0</span></span>
Endpoint</span> = <</span>IP of the server>:51820</span></span></code></pre>
Where <ip of the server></code> is the IP address of the server you want to use,
which can also be found in the list of servers on Mullvad's
site</a>. You will probably have some additional
fields in your config.</p>
The setup</a></h2>
We'll start by creating a new network namespace, aptly named vpn</code>:</p>
# ip netns add vpn</span></span></code></pre>
Then we roughly follow the steps from
https://www.wireguard.com/quickstart/#command-line-interface</a>:</p>
Add a new wireguard interface:</p>
# ip link add wg0 type wireguard</span></span></code></pre>
Move the device to our vpn</code> namespace:</p>
# ip link set wg0 netns vpn</span></span></code></pre>
From now on we will use ip -n vpn</code> to run the command in the vpn</code> namespace.
-n</code> is short for netns exec ip</code>, i.e., the command will be run in the provided namespace.</p>
Set IP address for the interface. The IP is found in the Interface.Address</code>
field in the config file, we'll use the v4 address.</p>
# ip -n vpn addr add <IP>/32 dev wg0</span></span></code></pre>
Use wg</code> to set keys and endpoints specified in the config file:</p>
# ip netns exec vpn wg setconf wg0 <config file></span></span></code></pre>
Activate the interface by setting it to UP.</p>
# ip -n vpn link set wg0 up</span></span></code></pre>
Make our interface the default route:</p>
# ip -n vpn route add default dev wg0</span></span></code></pre>Usage</a></h2>
We now have a network namespace named vpn</code> that will route traffic via your VPN
provider using WireGuard. To use it, prefix commands with ip netns vpn exec <command></code>. To verify that everything works, we run curl</code> in the same way
as before we started, but this time we run it in our network namespace:</p>
# ip netns exec vpn curl https://am.i.mullvad.net/connected</span></span>
You are connected to Mullvad (server gr-ath-wg-101). Your IP address is 132.133.134.134</span></span></code></pre>
And just to make sure, we'll also check that the result of running it outside
of the vpn</code> namespace hasn't changed:</p>
$ curl https://am.i.mullvad.net/connected</span></span>
You are not connected to Mullvad. Your IP address is 111.222.111.111</span></span></code></pre>
Success!</p>


Building Zola for Android
2024-07-29T00:00:00+00:00
This page is built using Zola</a>, a static site generator.
At the time of this writing there are no official builds or packages that can
be used in Termux</a> on Android. Rust and Cargo exists as
packages in Termux, so one option would be to build it directly on the mobile,
but for some reason Termux kept closing/crashing (probably oom killer or
similar), so here's how to cross compile it on a beefier machine. The steps are
for Arch Linux.</p>
Steps</a></h2>
Get the code for Zola, e.g.:</p>
$ git clone --depth 1 https://github.com/getzola/zola.git</span></span></code></pre>
Install android-sdk</code> from AUR</a> using your favorite method.</p>
Install cargo ndk</a>:</p>
# pacman -S cargo-ndk</span></span></code></pre>
Install the correct target platform for Rust, e.g.,</p>
$ rustup target add aarch64-linux-android</span></span></code></pre>
Build! The path to android-ndk</code> need to be specified for
cargo ndk</code> to find it.</p>
$ ANDROID_NDK_HOME=/opt/android-ndk/ cargo ndk -t aarch64-linux-android build --release</span></span></code></pre>
Now you should have a binary in target/<platform>/release/zola</code> that should
work in Termux. Good luck!</p>