Text files as a user interface - ratfactor

Update: After some feedback, I’m realizing that I need to do a better job of<br>explaining what I get out of this method versus other methods. I’m finding it’s<br>slightly nuanced and difficult to get across, so perhaps in the form of a list:

First, this card was originally titled A text editor as a user interface which was wrong and gave entirely the wrong impression. That was entirely my fault. Sorry!

This is not really about editing long commands. Shells have built-in<br>ways of doing that (e.g. Bash has the Ctrl-x Ctrl-e sequence).

I don’t want to create an in-editor interface controlled by<br>the text editor as in an ELisp extension in Emacs.

I don’t want to write any more Vim script than I have to, ever. I’ve done it,<br>thanks.

I don’t want to limit this to any particular editor at all.

This is usually part of a collection of command-line tools as a<br>personal ecosystem.

One of the biggest surprise advantages of this method is keeping the text<br>files around so that previous input is still there.

As a bonus, persistant editor undo history can even give you recently used values.

I added a new middle section, My image gallery tool example, which I think will get the point across much better.

Okay, on with the card:

A huge difference in effort lies between making a utility that takes a<br>few command-line arguments versus a full-blown text-based user interface<br>(TUI). Good user interfaces are hard work to make.

And yet, sometimes I want something in between. Something I’ve been<br>experimenting with lately is using a text editor as a user interface for<br>my programs.

Having a program launch your text editor (as specified in environment variable<br>$EDITOR) for you is a well-known idea. Here are three existing examples<br>right off the top of my head:

crontab -e to edit the cron table

git commit to edit the commit message

visudo to edit /etc/sudoers

vipw to edit /etc/passwd

All four open temporary files and allow you to edit them to your heart’s<br>content from the warm comfort of your favorite text editor and then<br>take that input and use it.

vipw makes a good example, since its entire purpose is to<br>ensure your edits are okay before applying them. From the man<br>page:

"vipw edits the password file after setting the appropriate locks,<br>and does any necessary processing after the password file is unlocked.<br>vipw performs a number of consistency checks on the password entries,<br>and will not allow a password file with a "mangled" entry to be<br>installed."

You, too, can use the power of text editing to control programs<br>of arbitrary complexity.

Tiny example

As a contrived example, let’s imagine I want the ability to write some<br>text and have it reversed with the rev utility.

This three-line shell script will open a temporary file with your<br>favorite text editor and then run its contents through rev, printing<br>the reversed result.

FILE=$(mktemp)<br>$EDITOR $FILE<br>rev

I told you it would be contrived. But you can see how simple the concept<br>is. I’ve given myself the full expressive power of my text editor with<br>just a single line. It would take me years to write my own ad-hoc TUI<br>of comparable editing power. And unlike an ad-hoc interface, I don’t have to explain how this one works!

My image gallery tool example

Over the years, I’ve really struggled with managing our digital family photo<br>"album". It needs to stand the test of time, so proprietary software is<br>right out.

I’ve slowly created a collection of Ruby scripts (and a PHP website served from<br>the home intranet web server) that create and manage a gallery based on:

Directories (broken up by year and event).

Text files.

Thumbnails generated on ingestion.

The "ingestion" phase is a script called gallery, and this is the piece I’d<br>like to focus on. Here’s the help text when you run it with no arguments:

Usage: gallery [dry]

Options:<br>dry do a dry run to see what would happen

Input:

inbox/ in output

Output:

set/<br>thumbs/ (all thumbs with md5 names)<br>description.txt (copy of inbox.txt)<br>thumb_map.txt<br>(all images moved here)

Verbose, right? But I almost never see this. The script is usually called from<br>a shortcut. My gallery directory almost never changes and so when it does, I<br>want this help message to be thorough!

The "Input" section is what this card is about:

The images to be added are sitting in and inbox directory.

Outside of that directory is a file named inbox.txt describing the images as a whole.

The format of inbox.txt is the real user interface.<br>Each line of the text file gives me different functionality such as<br>naming the set, tagging it, etc. The exact details aren’t important<br>so much as the fact that editing the text file has become incredibly<br>intuitive and fast.

The gallery script takes care of making thumbnails, creating directories,<br>moving files, etc.

Have you ever wished a traditional "UI" would just get out of your way<br>and let you edit the dang text?

Using this looks like this:

On one side, I’ve got a...