Daily Drivers Update; sqawk; shellbeats

This past weekend was the last one before #4 headed back to U Maine so he got priority over glowing rectangles.

---

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop. Ollama and MiniMax M2.1.)

• This section has updates to daily tools used include Joplin Cloud syncing, Shottr for screenshots, and new source home at Sourcehut.
• The sqawk project is a Rust‑based CLI that adds SQL querying to CSV/TSV files, with its repository serving as the main reference (https://github.com/jgarzik/sqawk/tree/v0.8.0)
• Shellbeats is a terminal‑only YouTube music player for Linux that now supports playlists and background downloads, hosted on GitHub (https://github.com/lalo-space/shellbeats)

---

Daily Drivers Update

A wee bit has changed since January 1st.

First, iCloud syncing for Joplin was fine while it lasted, but it was wonky on iOS/iPadOS. I have no mental capacity to add “run a standalone Joplin sync server” to the homelab, so I signed up for Joplin Cloud and am not going back. It’s great. Super easy to set up and works great. I turned a very old iPad into a kitchen glowing rectangle and it’s great having recipes I’ve got in there (which I’m keeping since I’ve not seen an “export” button in Cooked.wiki) at the ready again. It also feels pretty good supporting this great open source project.

Second, I did indeed get my access to Sourcehut restored! You can find me there at https://sr.ht/~hrbrmstr/. I’ll be migrating stuff from Codeberg when mods to a given project are needed, or when I make some new stuff like this Golang port of MotherDuck’s Python-based DuckDB MCP server. I am finding that dependency-free MCP servers are the way to go, and this has been battle tested over the past week at work.

I’ll also be posting a tiny Deno script that will sync new items from Raindrop.io to Joplin. I think I may be able to ditch Raindrop.io this year now that I finally have that working well. Will drop a link to Sourcehut later this week.

I’ve also switched from using the built-in macOS screen capture tooling to Shottr. It’s fast, has way more editing options including “blur”, which I am finding an increasing need for. You can also snag it via Homebrew.

---

sqawk

We need to make something clear right off the bat. I am not recommending folks use sqawk for SQL ops on files in the terminal. DuckDB has had contact with the enemy (we data analysts) for far longer and likely does most things better (I couldn’t figure out how to pipe stdin to sqawk, and I’m not exactly a daft person). I’m posting it since when I did get it working, it does what it says on the tin, and is a ridiculously well-designed Rust project. Since Rust is all the rage in our new “memory safe” world, this is something to clone and pore over if you get the Rust bug or are forced into the Rust evangelism strike force.

I’m also including it since it’s a demonstration of what appears to be responsible use of an LLM coding assistant.

The TL;DR for sqawk (which is a royal pain to type) is that it is a Rust-based CLI tool that brings SQL query semantics to delimiter-separated files (CSV, TSV, etc.) without requiring database server infrastructure. The architecture follows a straightforward pipeline: files are loaded into in-memory table structures, SQL statements are parsed via the sqlparser crate, compiled to bytecode, and executed through a register-based virtual machine directly inspired by SQLite’s VDBE. The VM instruction set includes ~70 opcodes covering cursor operations, comparisons, aggregates, joins, sorting, and DDL/DML—enough to support a surprisingly complete SQL dialect including SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, window functions, subqueries, and set operations like UNION/INTERSECT/EXCEPT.

The execution model uses cursors to iterate over table rows, with registers holding intermediate values during expression evaluation. The compiler (vm/compiler.rs and related modules) walks the sqlparser AST and emits bytecode that the engine (vm/engine.rs) interprets. This design cleanly separates parsing, compilation, and execution phases while keeping the codebase tractable (i.e., each compilation concern — aggregates, joins, window functions, DDL, DML — lives in its own module). Tables track their source file paths and modification status, enabling a conservative writeback model where changes remain in-memory unless you explicitly pass --write.

The data model is equally well-considered, as tables own their rows and track metadata (source file path, delimiter, modification status) which makes the “safe-by-default” writeback model trivial to implement (we just need to check modified flags at the end). The Value enum handles the four core types (Integer, Float, String, Boolean) plus NULL, with proper type coercion and comparison semantics baked in. The cursor abstraction unifies access to both real tables and ephemeral tables (used for sorting and intermediate results), so the VM doesn’t need special cases. Using Rc<str> for string parameters in bytecode instructions avoids cloning strings on every instruction fetch in the hot loop.

Looking through the Rust sources (half in an attempt to keep Rust coding in muscle memory) and exquisite documentation (it is someting coding LLMs are pretty good at) was a way better bit of time use than doomscrolling. Doing so also made it clear that both ReplIt’s LLM coding assistant as well as Claude were both used. Yes the CLAUDE.md and “agent” in .replit were pretty obvious, but say they weren’t there. What are the “tells”?

Every file opens with a boiler‑plate “one‑line summary → bullet list → # Arguments / # Returns” block, even for private helpers like count(). Real Rust code rarely over‑documents internal methods, so the uniform, exhaustive doc comments are a classic LLM pattern.

The commit history also uses generic, promotional phrasing (“Equip the query tool…”, “Add functionalities…”) and a step‑by‑step “Phase X” roadmap. We humans are generally not known to write commit logs that read like product‑announcement copy or a pre‑planned phase outline. That may not be true in extremely formal dev teams, but it does seem overkill for a side project.

Finally, in the code itself, functions contain verbose, pedagogical notes (e.g., the PartialEq impl for SqawkError explains why it only checks variant names, “useful for testing”). Likewise, opcode enums are fully listed with “not yet used” comments, reflecting an LLM’s habit of generating the complete spec up front rather than evolving the code incrementally.

None of that is a detraction, but we’re all going to start seeing more LLM assisted code, and I think it’s a good idea to get used to sizing up the tells (in projects that leave CLAUDE.md, et al., out of the git work tree) so you can decide for yourself whether you are comfortable relying on any given codebase.

---

shellbeats

One bit of glowing rectangle time I don’t mind at all is terminal time.

While I cannot listen to music while writing code or prose, I can do so when reading such content, and I have had quite a bit to read of late. I hate using browsers for playing anything, and Apple’s Music app UX is a bona fide joke. For various reasons I have full access to YouTube/YouTube music, so was keen to check out a new CLI utility for dropping some beats whilst consuming text-based content.

Shellbeats is a pure‑terminal music player for Linux that treats YouTube as a “cloud music store”. When you type a query, the program calls yt‑dlp to fetch a list of video IDs, displays them in an ncurses UI, and then hands the chosen URL over to mpv for audio‑only playback. The clever part is the IPC socket that links Shellbeats to mpv: the player reports events (e.g., “end‑file”) back to the UI, allowing the app to auto‑play the next track without busy‑waiting. All state (playlists, configuration, download queue) lives under ~/.shellbeats/, so the next time you start the program you pick up exactly where you left off.

The new v0.3 release adds playlist management and a background download engine. Press f to open the playlists pane, where you can create, delete, or edit playlists; a adds the currently selected song to a playlist; d queues a song (or an entire playlist) for download. Downloads run in a separate pthread and will be saved as MP3 files into ~/Music/shellbeats/<Playlist>/ (they’re also marked with a [D] tag in the UI). The download queue is persisted as JSON, so interrupted downloads resume automatically, and playlists are “smart”: if a local file exists Shellbeats streams it instantly; otherwise it falls back to YouTube streaming. Deleting a playlist also wipes its folder, keeping disk usage tidy.

Not bad for a 3K-line, single-file C-based project!

---

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• Bluesky via <https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy>