revenge of the kludge

Source

I'm playing with termux-api, which exposes a bunch of Android API things to the termux command-line environment. I'm kind of afraid that I'm going to hack together an app using the command line. Excellent and hilarious and a terrible idea. The kind of procrastination that looks like work.

The termux-api package exposes a bunch of Android API functions through command-line programs that emit JSON text on stdout:

$ termux-battery-status
{
  "present": true,
  "technology": "Li-ion",
  "health": "GOOD",
  "plugged": "UNPLUGGED",
  "status": "DISCHARGING",
  "temperature": 28.6,
  "voltage": 4195,
  "current": -366516,
  "current_average": null,
  "percentage": 81,
  "level": 81,
  "scale": 100,
  "charge_counter": 4126576,
  "energy": null,
  "cycle": 0
}
$ termux-fingerprint
{
  "errors": [],
  "failed_attempts": 0,
  "auth_result": "AUTH_RESULT_SUCCESS"
}

I'm not totally certain where I can find the manual pages for these tools. They all have brief -h help documentation, but I would be interested to see something more comprehensive. When I read documentation from front to back, I learn things.

For example, I did just discover that I can enable the Android predictive text input modeby swiping the "extra keys" row off to one side. That's going to make actually exciting here on the phone much less annoying.

I'm trying to imagine a toolkit where I can just write on the phone and have it appear in this nice text tool that I've been using. The other day, on the phone again, I wrote a fairly sophisticated tool for synchronizing a text file located outside of the nikola source tree, including its dependent assets, with a folder visible to the markdown-aware Markor text editor. However, now that I have discovered how to use the Android predictive input when I'm interacting with Emacs, I feel a lot less need to pursue that project further. On the other hand, it would be nice to manage some of my system interactions using things like Android notifications. For instance, it's nice to be able to termux-open-url in order to get the browser to look at the current state of the page. Slower than the Markor preview panel, but still fine.

If I'm going to integrate the various termux-* tools into my build process, I should invest a little time figuring out whether they can be accessed within a Python module. I am doing a fair amount of old-fashioned shell and make programming in this lovely Python framework, which is getting the job done, but not really serving my educational purpose.

So: Python bindings? Or subprocesses with JSON output and pipes? [2025-07-07 Mon 13:09] … [2025-07-07 Mon 13:20] It looks like subprocesses and pipes. Oh well.

Just kidding, it looks like I'm doing this today.

I've discovered libtmux for controlling the tmux terminal multiplexer. (Unfortunately tmux is a different creature from termux, the Android app which exposes a Linux system, and I'm using both here.) And I now have a little Makefile section which will create the long-running processes in two tmux panes — a bit of automation that I have wanted for a while now.

First, let's write a shell script that will connect to a tmux session in a termux window on the phone.

Got that. I needed termux-widget, which I had trouble installing because I accidentally tried to mix sources for the different termux packages. Now scripts that I place in ~/.shortcuts can be run from the phone's home screen, and scripts that I place in ~/.shortcuts/tasks can run in the background.

I have a one-liner that opens a tmux session in the terminal with the right name:

#!/bin/sh
tmux new-session -c nikola/robtasm -s nikola || tmux attach -t nikola

Hmmm, now I know about tmuxp, which I think I was about to try to write poorly.