The problem with this kind of tool is that it competes with Notes.app, Numbers.app, Google Docs, Excel, notepad.txt which are much simpler than remembering how to use some bespoke CLI app every time you finish a book and then figuring out how to back up the database. And being unable to log a book because you don't have your laptop around.
One idea is to use a spreadsheet as a back-end (like an iCloud-stored Numbers.app spreadsheet on macOS and a OneDrive Excel doc on Windows) with a simple human-editable structure, and your CLI tool is a front-end for interacting with it, exporting/importing from services, basically a value-add on top of a document that users could edit by hand.
i have been working on my own tool to track books and tv shows. i started as a way to learn lisp. it was fun for a while, but i eventually abandoned it because the commandline interface entering one field at a time was just to clunky.
i went back to editing a plain text file.
some day i want to get back to having a terminal tool, but the key features it needs to have are:
a way to edit fields all at once either using some nice TUI library where i can use tab and cursors to jump from field to field, or what git does, throw me into an editor to add the line.
it also needs to allow me to look at past entries somehow, to make it easy to add episodes/chapters/sequels without having to repeat all the data that is shared.
currently i do that by simply copying an old entry and editing that.
The way I see it there's a risk any of those (eg notion or goodreads) goes under a sudden paywall, price increase and big friction around extracting your data. With this you just have to save the sqlite file wherever you backup the rest of your data.
Hey, this is cool! I’m working on an open source, self-hostable ebook library, made to solve the 80%-usecase of Calibre. I also built a command line interface to interact with its database, but this is stock-Full of nice ideas. I might steal some! :)
My plan is to query several public data sources [from within a web worker on the client, to avoid restrictions], such as WikiData, ISBN DB, the Library of Congress API, GoodReads, and a few others. There's really a lot of open data available; I want Colibri to automatically pull in metadata on books and authors, if possible.
I have prototyped a lot on this, but not published it yet. It works pretty well :)
Yes, although I wouldn’t take that code at face value; the OpenLibrary implementation was more of a test to see how flexible an implementation of the metadata service can be.
When ready, these will be documented and extensible!
It doesn't look like it can be used to track and cross-reference short stories.
Short stories can be stand-alone (web based), found in an anthology, a book collection or published in a magazine.
What would be nice is a tool to track where I read a short story (in anthology A, for example), and where the story can be found, which may be in more than one place (in magazine B, collection C, on-line, etc.).
This is, unfortunately, also not supported in many other book sites like Goodreads, etc.
honestly, I've settled for a single text file. if I read something, I make a note in Google keep and transfer it to the text file when I get home. it's an org file that gets converted to html and synced to my phone along with everything else in the shared folder, but the point is that it's a flat file and I can grep or C-s.
I discovered Audiobookshelf over the weekend and it seems like the ultimate self hosted solution for audiobook and ebook management. Mobile apps, user accounts for the kids, great metadata support.
Audiobookshelf has become a key service in my self hosted stack. I use it primarily for podcast management and it’s been wonderful. I use plappa on iOS as my client and the offline support is stellar. I’m building a FreeBSD port for it too so it can have a forever home on my stable server.
A basic command-line tool to track your books read, show some basic stats and charts. All stored in a sqlite3 database and you can import from a Goodreads export CSV.
I used mostly Claude 3.7 but recently been trying out Gemini 2.5 Pro which works really well too. AI really makes projects like this easy, it's a basic tool and doing simple tasks of converting or selecting data.
From the examples, it looks like this command-line tool should be able to be generalized to catalogue arbitrary data (retro gaming, tabletop games, movies, ...) with the same graphs/statistics/table, only with slightly larger overhead when querying the store. Along with a new command to create the catalogue and its columns of course.
> catalogue new --numeric id, year, rating --text title, author
> catalogue show --column id --value 123
> catalogue show -c year -v 1984
> catalogue report -c author (would show generic "Count" rather than "Books read")
Could also be extended so the user can provide a SQLite db name to create/use so you have a db per catalogue.
I've probably forgot some things as I'm just typing this out loud, but that's my general idea?
Cool. I like using the cli for almost ever, but somehow for books, I gravitate more towards something with a GUI. I use Zotero nowadays; seems enough for now.
I think they're just telling OP that the name might generate confusion. If that's the case, I don't really agree. "Libro", as you point out, is just Italian (and Spanish, fwiw) for "book".
Try a short story collection. Ten page chunks are easy to consume and you get to tell yourself you’re reading literature. It’s a good way to get back into reading on paper if you’ve been away and want to start small.
One idea is to use a spreadsheet as a back-end (like an iCloud-stored Numbers.app spreadsheet on macOS and a OneDrive Excel doc on Windows) with a simple human-editable structure, and your CLI tool is a front-end for interacting with it, exporting/importing from services, basically a value-add on top of a document that users could edit by hand.
reply