Building an RSS Reader in 80 Lines of Bash: A Journey to Simpler Dependencies

The quest for digital minimalism often leads developers down unexpected paths, and sometimes the most satisfying solutions emerge from stripping away complexity rather than adding to it. This journey into building an RSS reader with nothing but bash and core Unix utilities reveals both the power and limitations of working close to the metal of our operating systems.

The motivation behind this project stems from a common frustration among power users: dependency fatigue. When your daily workflow relies on third-party software, you're essentially placing trust in strangers' code—code that might break your system through an accidental bug or, worse, a malicious commit. The author's previous setup with Newsboat worked well enough, featuring a macro that appended links to a markdown file, followed by a morning ritual of processing these links through w3m and vim. But the desire for something simpler, more hackable, and entirely under personal control proved irresistible.

Initially, the temptation was to reach for a modern systems programming language like Zig, which the author had been exploring recently. However, a moment of clarity revealed that the omnipresent Unix tools—curl, grep, awk, sed—were more than capable of handling the task. This realization speaks to a broader truth about software development: sometimes the most elegant solution is the one that leverages existing, battle-tested tools rather than building something new from scratch.

The architecture of this minimalist RSS reader is deceptively simple. The core idea involves fetching feeds in parallel using xargs, processing each feed through a bash script, and appending results to a central file while using flock to prevent race conditions during concurrent writes. This approach demonstrates a fundamental principle of Unix philosophy: small, focused tools working together can accomplish complex tasks.

Parsing RSS feeds with regular expressions might raise eyebrows among purists, but it works surprisingly well for this use case. The script downloads the feed, splits it by item/entry tags using awk, and normalizes whitespace to simplify subsequent processing. The decision to limit the number of items processed addresses a practical concern—many feeds simply append new items without removing old ones, and processing thousands of entries every time would be wasteful.

The filtering system represents perhaps the most sophisticated aspect of the implementation. Drawing from experience with Newsboat's filtering capabilities, the author built a system that can apply rules globally (using the * wildcard) or per-feed. The syntax allows for blocking specific domains like Medium or Substack, filtering out YouTube shorts, or excluding particular arXiv submissions. This granular control over information intake reflects a growing awareness of how digital consumption patterns shape our thinking.

One particularly clever aspect is the hashing mechanism used to avoid processing duplicate items. Rather than hashing the content (which could change as comments accumulate or pages update), the script hashes the combination of title and links. This approach has trade-offs—it might miss gradual content updates—but it effectively prevents the same article from appearing multiple times in the reading list. The use of md5sum for this purpose is pragmatic; cryptographic security isn't the concern here, just consistent identification.

The content extraction process uses w3m in text mode to convert HTML to plain text, with a character limit to prevent overwhelming the reading list. This choice reflects a thoughtful balance between preserving context and maintaining usability. The script checks multiple potential content fields (description, summary) and applies filters at each stage, ensuring that unwanted content never makes it into the final output.

There's an honesty in acknowledging the limitations of this approach. The parsing is naive and will break on some feeds. The output can be ugly. The filter system hasn't been thoroughly tested and likely contains bugs. Yet these imperfections are part of the charm—this is a tool built for personal use, not mass consumption, and its rough edges are acceptable trade-offs for its simplicity and transparency.

The parallel processing implementation using xargs and flock is worth examining more closely. By spawning multiple instances of the feed processing script and using file locking to serialize writes to the shared state file, the author achieves significant performance improvements without sacrificing data integrity. This pattern—embarrassingly parallel tasks with shared state—appears frequently in systems programming and represents a practical application of concurrency control.

What makes this project particularly interesting is how it sits at the intersection of several important trends in software development. There's the move toward minimalism and reducing dependencies, the resurgence of interest in Unix philosophy and text-based workflows, and the growing awareness of how our tools shape our information consumption. By building something simple and personal, the author has created not just a functional RSS reader but a statement about the value of understanding and controlling one's digital environment.

The full script, weighing in at around 80 lines, demonstrates that complex functionality doesn't require complex code. Each component serves a clear purpose: curl for fetching, awk for parsing, grep for filtering, w3m for content extraction, and basic bash constructs for control flow. The result is a tool that, while not as polished as commercial alternatives, offers something they cannot—complete transparency and the ability to modify it to suit changing needs.

This project also raises interesting questions about the future of information consumption tools. As we become more aware of how algorithmic feeds and recommendation systems shape our worldview, there's growing interest in tools that give users more control over their information diet. An RSS reader built with explicit filtering rules and manual curation represents a different philosophy from the automated, engagement-optimized systems that dominate social media.

The journey from dependency on Newsboat to creating a personal RSS reader encapsulates a broader shift in how some developers approach their tools. Rather than accepting the limitations and risks of third-party software, there's a movement toward building simple, understandable alternatives that can be modified and maintained independently. This isn't about rejecting all external dependencies—curl, grep, and w3m are still external—but about choosing dependencies that are stable, well-understood, and unlikely to change in breaking ways.

For those interested in exploring this approach, the script provides a solid foundation. The filtering syntax is intuitive, the parallel processing offers good performance, and the overall structure is easy to understand and modify. While it may not replace sophisticated RSS readers for everyone, it serves as an excellent example of how much can be accomplished with minimal tools when approached thoughtfully.

The beauty of this solution lies not in its sophistication but in its honesty. It doesn't pretend to be a polished product; instead, it's a personal tool built to solve a specific problem in a way that the author can understand and control completely. In an age of increasingly complex software systems, there's something deeply satisfying about a solution that can be read, understood, and modified in its entirety by a single person.

This project reminds us that sometimes the best tool isn't the most feature-rich one, but the one we understand completely and can modify to meet our exact needs. It's a testament to the enduring power of Unix philosophy and the satisfaction that comes from building our own solutions to everyday problems.