~iany/ Script

Forwarding Desktop Notifications to Pushover

me@iany.me (Ian Yang) — Tue, 08 Sep 2026 09:00:00 +0800

I already forwarded mako notifications to Pushover on Linux. The hook is tiny: mako runs a command with the notification id, the script reads makoctl list -j, skips loops and Pushover itself, and POSTs to the Pushover API.

Windows has no equivalent of on-notify=exec. I wanted one binary, dn-pushover, that does the same job on both desktops: titles become [DN][hostname] … so a notification that bounces back is easy to drop.

Linux stayed simple. Windows did not.

How it works

Linux. dn-pushover setup writes a managed block into ~/.config/mako/config:

on-notify=exec dn-pushover "$id"

Then it reloads mako. If makoctl is missing, setup fails instead of pretending to work. An old mako-pushover block is migrated so deleting the old binary cannot leave a dead hook behind.

Windows. There is no desktop-wide exec hook. The supported API is UserNotificationListener: after the user grants access, an app can read other apps’ toast notifications. setup therefore:

Checks Pushover credentials.
Builds a small C# WinForms helper (first time only; later setups reuse the exe).
Packs a sparse identity MSIX (manifest + logos; the exe lives next to it via -ExternalLocation).
Signs it and registers it.
Launches the helper. You click Allow Access and accept the Windows prompt.
The helper baselines whatever is already in the notification center, then polls for new toasts and runs dn-pushover --forward with JSON on stdin.

teardown stops the helper. teardown --cleanup also unregisters the package and deletes %LOCALAPPDATA%\dn-pushover. There is no autostart: after logout, run setup again.

The JS side is shared: prefix, truncation, skip [DN] / [mako] / recognizable Pushover traffic, then send().

Gotchas

Linux is a hook. Windows is an identity.

UserNotificationListener is not “read the notification database.” It is a capability on a packaged app. An unpackaged Win32 process can call RequestAccessAsync and even get Allowed while GetNotificationsAsync returns an empty list and Settings never shows the app.

A loose Add-AppxPackage -Register development package (SignatureKind=None) has the same problem. Windows will not list it under Privacy & security → Notifications (the read list, not System → Notifications, which is the send list).

What worked was a signed sparse MSIX whose publisher matches the exe’s app.manifest msix element, with uap3:Capability Name="userNotificationListener" and AppListEntry not set to none.

Signing is not optional, and per-user trust is not enough

Self-signed is fine for a personal machine. The private key stays in CurrentUser\My. Importing the public cert into CurrentUser\TrustedPeople does not make you a public CA; it only means this user trusts this publisher.

MSIX deployment still failed with 0x800B0109 (untrusted root) until the public cert was also in LocalMachine\TrustedPeople. That needs a one-time UAC. Later setups skip the import if the thumbprint is already there.

powershell.exe -NoProfile has no Cert: drive. Import-Module PKI under $ErrorActionPreference = 'Stop' blew up on duplicate type data. Certificate create/import had to use X509Store / CertificateRequest instead of New-SelfSignedCertificate.

The SDK is not the runtime

A .NET 10 runtime cannot dotnet publish. First Windows setup needs a .NET 10 SDK (Scoop: versions/dotnet-sdk-lts) plus Windows SDK tools makeappx and signtool. Setup runs PowerShell with -NoProfile, so Scoop’s shims are not on PATH; it has to look in ~/scoop/apps/dotnet-sdk-lts/current/ itself.

Setup also skips rebuilding if the helper exe already exists, and used to skip re-registering if the package was already installed. That is how a stale unsigned package and an old helper survived “I already ran setup.” teardown --cleanup is the rebuild switch. Signed packages under WindowsApps must actually be removed; if cleanup no-ops, Get-AppxPackage will still show them.

The compiled Bun binary is a different program

import.meta.main is false inside a Bun-compiled .exe. Guarding main() with only that flag made dn-pushover setup exit 0 with no output. Detect the virtual B:/~BUN/ / $bunfs entrypoint as well.

Bun.stdin.text() in that same compiled Windows exe did not read the helper’s piped JSON. --forward exited 0, sent nothing. readStdin() from Node’s process.stdin did. A WinForms AcceptButton also treated the Enter key from the terminal as Allow Access, so setup “returned immediately” after the first successful grant.

Substring /pushover/i on the app id matched DnPushover.NotificationListener and dropped every toast. Skip the Pushover product, not any name that contains those letters.

Debug process

The failure mode was always the same from the outside: a Windows toast appeared, Pushover stayed quiet. The pipeline has three stages; each can succeed while the next never runs.

Is the listener alive? Process + %LOCALAPPDATA%\dn-pushover\listener.log. Empty log with a running process meant polls were not seeing new toasts (or the form was hidden and the timer never ticked). Listener ready; N existing toast(s) means those N will never be forwarded — send a new toast after ready.

Does JS send? Pipe JSON into dn-pushover --forward and watch the Pushover API. A 200 body {"status":1,"request":"…"} means credentials and the API are fine. If that works and the listener still does not, the helper is not invoking the CLI you think it is (config.json points at dist\dn-pushover.exe), or the CLI is skipping the payload.

What did --forward actually do? Temporary logging of argv, stdin length, skip vs send, and the API status. That is how Bun.stdin.text() was caught: argv logged, stdin never read, process exit 0, no HTTP. After the stdin fix, the same toast showed apiStatus: 200. Edge then showed the Pushover copy with a [DN] title; that one is supposed to be skipped so you do not loop.

Direct fetch to https://api.pushover.net/1/messages.json (user key + desktop-notification token, no secrets in logs) is the ground truth. If that returns status: 1 and the device still shows nothing, you are looking at the wrong Pushover app or device, not at this script.

Practical checklist

Linux: makoctl on mako’s PATH; dn-pushover setup; section-specific on-notify rules win over the global hook.
Windows: .NET 10 SDK + Windows SDK; one UAC to trust CN=dn-pushover in LocalMachine\TrustedPeople; dn-pushover setup; click Allow Access; Privacy list is access, not senders.
After changing helper C# or the Bun CLI: teardown --cleanup then setup, and use the rebuilt dist binary.
Test with a toast created after the listener is ready. Expect [DN][hostname] on Pushover.

Use Bun for Shell Scripts

me@iany.me (Ian Yang) — Sat, 07 Feb 2026 00:00:00 +0800

I’ve moved most of my small scripts to Bun. It sidesteps Windows’ lack of shebang support and the Git-for-Windows/WSL bash dance, and gives you one runtime for both ad-hoc shell-style commands and full scripts.

Problems Bun solves

Windows doesn’t execute #!/usr/bin/env python3 or #!/bin/bash, so scripts written for Linux or macOS usually need a separate PowerShell version. Bun compiles JavaScript to native executables, so a single script can run cross-platform without shebangs.

Mise file tasks have started to support shebangs on Windows in the latest release, but they rely on system bash.exe, which often points at WSL. Bun does not. You run bun ./script.js and embed shell commands via Bun.$; the script uses Bun’s bundled bash environment.

Why Bun for shell scripts

The command bun build ./script.ts --compile --outfile script produces a single binary, so no shebang or interpreter is needed on Windows. The Bun.build API is available too; I use a build.js script to walk a directory and compile all executables. Pre-built binaries start quickly—Bun’s docs cite ~5ms vs Node’s ~25ms for a simple script, which helps for small, frequently run scripts.

Bun has strong support for shell-style scripting. Bun Shell runs bash commands; the main entry point is Bun.$, which constructs shell commands from template literals for safe interpolation, similar to google/zx. On Windows, Bun ships with MSYS, so you get a consistent bash environment and common Linux CLI tools without extra setup.

Other useful features:

Bun.secrets—Securely store and retrieve secrets using the OS keystore (Windows Credential Manager, macOS Keychain, Linux libsecret). Secrets - Bun
Built-in support for glob patterns, YAML parsing, ANSI colors, and more. Bun Runtime

Short example

import { $ } from "bun";
const out = await $`echo hello`.text();
console.log(out); // hello

Run it with bun run script.js or bun ./script.js.

Obsidian Notes

JavaScript Shell Scripting

Switch Window Using Fuzz Matching

me@iany.me (Ian Yang) — Wed, 25 Aug 2010 00:00:00 +0000

This article demonstrates how to quickly switch to a window using gpicker and wmctrl. You type significant letters of workspace name, application name or title and gpicker provides a list of windows you most likely mean to pick.

Gpicker

Gpicker is a program that allows you to quickly and conveniently pick file in a (possibly very large) project. You type significant letters of file name (typically from the start of words) and gpicker provides you with a list of files you most likely mean to pick. The program filters and orders project’s list of files in real-time as you type.

You need to download and install it manually (for Ubuntu, you can download the Debian package).

Gpicker is designed as a filter, so it can be used to select item from an arbitrary list. The selected item is printed on standard output.

For example, use gpicker to select a number between 1 and 10:

$ seq -w 1 10 | gpicker -n "\n" -

Gpicker picks 1 to 10

The last dash tells gpicker to read list from standard input, and option “-n” sets the list separator. Gpicker uses “\0” as item separator by default.

Wmctrl

Wmctrl is a command line utility to interact with a EWMH/NetWM compatible X Window Manager. It can list all windows, switch to a window or bring a window to current workspace. Wmctrl can be installed by package manager in most Linux distribution.

Wmctrl lists all windows using option “-l”. We can add “-x” to list windows resource and class as well. The output of wmctrl -l -x looks like:

0x03200009 0 urxvt.URxvt ian-desktop urxvt
0x0340008e 1 Navigator.Firefox ian-desktop Vimperator / test
0x03e000a4 2 emacs.Emacs ian-desktop Emacs: _theme.sass

The first column is the window ID. We can switch to or bring a window using the ID.

# switch to Emacs, raise and focus it
wmctrl -i -a 0x03e000a4
# bring Emacs to current workspace, raise and focus it
wmctrl -i -R 0x03e000a4

Windows Picker

Now we can use wmctrl to list windows, gpicker to select one window, and wmctrl again to switch to the selected window.

wmctrl -i -a `wmctrl -l -x | gpicker -n "\n" -d "\n" -`

The directory separator is set to “\n” in the first windows picker above, because gpicker is designed to pick files primarily and it has special rules in the matching algorithm.

First the item is split by directory separator. Before we enter a directory separator ("/" by default), only the last component (it is the file name if the item is a file path) is used in matching. For example, “bin” does not match item “bin/ruby”, but “bin/”, even “b/” does match. If the window title contains the directory separator, for example the Firefox in the wmctrl -l -x output above:

0x0340008e 1 Navigator.Firefox ian-desktop Vimperator / test

To match it, we must enter “firefox/”. So I set directory separator to “\n” to disable this feature, and the whole item is used to match.

However, we can take advantage of this feature. If we construct the window item likes:

id/workspace/window_class/window_title

I can match window title by type significant letters directory. I also can use directory separator “/” to filter all windows in a specific workspace, or windows with the same window class.

It is very useful for me. Because I uses tiling windows manager Xmonad and places windows in different windows. Following are some examples:

I have entered	Windows I want to match
www/ff/	Firefox in workspace “2.www”
ruby	Windows which title contains ruby
xpdf/ruby	A document opened using xpdf and the title contains ruby
sys/usrshare	The terminal I opened visit /usr/share in workspace “1.sys”

Sure, we have to remove “/” from workspace name and window title.

I use a Ruby script to format the list. Workspace name can be listed using wmctrl -d.

Now we can use the ruby script in the revised version:

wmctrl -i -a `wlist.rb | gpicker - | sed 's;/.*$;;'`

Replace “-a” with “-R” to bring window to current workspace.