I recently participated in the Handmade Network Visibility Jam and built a tool that I’d been wanting for my own use:

In a nutshell, Escape Artist shows ANSI escape sequences that are normally invisible. It’s kinda like View Source for the terminal; my hope is that it will be useful for anyone working on shells and terminal applications.

Tech Stack

Escape Artist is primarily written in Rust, using Axum to serve up a web UI using Tailwind+Preact. Events get streamed to the front-end over a websocket. I took great pains to keep the front-end simple; nearly all business logic lives in the Rust back-end, there is no front-end build step, and all dependencies are bundled with the application.

Escape Artist compiles down to a single-file 1.8MB executable, and nearly half of that is Tailwind and an embedded font.

Lessons Learned

Parsing escape sequences out of a stream of bytes is remarkably tricky. Thankfully the vte crate does most of the heavy lifting for us.

This minimal approach to web UI was generally pretty nice! I occasionally ran into a bit of trouble wrangling JS libraries that assume everyone is using NPM, React, and a bundler like webpack, but overall it wasn’t too bad.

I ended up needing to roll my own tooltip solution using Floating UI, and… wow. Their introductory tutorial is one of the best I’ve ever seen for a library in any language.

I work on a command-line shell called Nushell (Nu for short) with some internet friends, and I think it’s pretty cool. To convince you that it’s cool (or at least worth a try), here’s a whirlwind tour.

Basic Querying

Let’s start by taking a look around the filesystem. We’ll use ls to take a look at the files in /usr/bin:

Like many other people, I unexpectedly found myself stuck at home without much to do in early 2020. To stay sane, I set about answering a question I’d had for a while: what’s the deal with native GUI frameworks on Windows these days?

It’s rarely obvious which of Microsoft’s several supported technologies is the best choice for a new project, and Windows doesn’t have the same culture of idiomatic+consistent native GUIs as macOS. After months of obsessive escapism focus I emerged with a decent understanding of the problem space; let’s start with an overview of the technologies in use today:

Win32

This is kind of a catch-all term for the old-school way to build a Windows application using arcane, less-than-ergonomic C APIs. This is unpleasant and your application will look ugly, but one big advantage is that the Win32 APIs will live forever and they underpin all the other UI frameworks.

It’s well worth your time to learn a bit of this (read Charles Petzold’s book ), but it’s rare to see people building pure-Win32 GUIs these days.

Say you want to host some files in an S3 bucket, under your own custom subdomain with nice short HTTPS URLs. For example, you own foo.com and you want files to be accessible at URLs like https://files.foo.com/bar.txt.

This is a lot more complex than it should be! It involves configuring 3 separate AWS services and I’m already forgetting the boring details, so let’s write them down for future reference.

Cloud is the future… wait, 3 separate AWS services?

YEP.

…

Creating the S3 bucket

Naming is important here - the S3 bucket must have the same name as the subdomain it will be accessed at. Open up S3 in the AWS console, and:

1. Create a new bucket named files.foo.com.
2. Disable “Block all public access”.
3. Under the bucket’s Permissions tab, add a bucket policy to make all objects public by default (replace files.foo.com with the name of your bucket):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::files.foo.com/*"
        }
    ]
}

Certificate Creation+Config

Next up, we need to create a certificate in AWS Certificate Manager.

Hot Tip

Certificates must be created in the us-east-1 region to work properly with CloudFront. Learn from my mistake, make sure you’re in the right region when performing this step.

I’ve joined the Nushell core team. This doesn’t really change what I’m doing day-to-day, but it makes my work on Nu feel a little more official 🙂.

SQLite Support

This is the biggest feature I’ve implemented so far:

I’m pretty proud of how this turned out; it’s very convenient to be able to browse SQLite databases in your shell and interact with them the same way you would any other data source. Nu is often-but-not-always smart enough to avoid unnecessary work when loading things from the database; there’s still some work to do here and it will probably involve rearchitecting how Nushell queries data.

File watcher

I also implemented a watch command that runs arbitrary Nu code in response to file changes. Nothing groundbreaking, but I find myself needing this kind of low-key automation all the time: run tests when code changes, restart a development server, log changes in a directory, etc. I think the ability to respond to file changes should be a more widely available primitive, and now it is.

Rust for Windows

Against all odds, I somehow got sucked back into Windows development. I spent a solid week helping one of Nushell’s dependencies do a big upgrade of their Windows functionality. This required a deep dive into the current state of calling Windows APIs from Rust, and… it’s a mixed bag.

I used the windows crate which is maintained by Microsoft. It’s an automatically generated set of Rust bindings for Windows APIs, which is both good (very comprehensive, always kept up to date) and bad (some rough edges that might be solved in a handmade solution like winapi). The crate is actively being worked on and it frequently has breaking changes; this means documentation is a little scarce and often out of date. Overall I was impressed and I think the crate has a bright future . But until it settles down a bit, expect some growing pains.