There's a certain kind of bug that doesn't make you feel stupid because it's complex. It makes you feel stupid precisely because it isn't.
That was my day today.
I'm building Kron — a multifunctional CLI tool for file inspection and manipulation, written in C++20 with zero external dependencies. I'm currently working on a new command: copy. But before I could write a single line of it, I had to deal with the global --version and --help flags first.
The flag bug
The logic was simple: --version and --help need to be handled before any command is dispatched. If someone runs kron --version alone, the program should print the version and exit — not throw an error because no command was provided.
I overcomplicated it at first, trying to figure out the right place to intercept these flags in the pipeline. Eventually I found it: right after options are normalized, before command processing begins. That way the flow gets cut early and nothing downstream runs.
--help was similar, with one extra condition: if a command is provided alongside --help, it should print that command's help and stop execution. Clean, simple.
Then I spent way too long debugging why a command with no options wasn't executing at all. The culprit? A stray else in the dispatch logic that should have been removed. It was blocking execution entirely for commands called without options. Classic.
The copy command
The core data extraction logic in copy is similar to what inspect already uses, which made the foundation straightforward. The standard functionality is all there — recursive copy, force overwrite, skip existing files, preserve metadata, dry run, verbose output.
But I want copy to do something the traditional tool doesn't: filter what gets copied. By extension, by file size, by date, by permissions. So instead of blindly copying everything, you can tell Kron exactly what you want moved and what should stay behind. More control, less cleanup.
The performance problem
list and inspect already use multithreading for data collection, and the filtering logic is as optimized as my current knowledge allows. Both commands handle simple workloads well.
The bottleneck is printing. When dealing with large volumes of data, output slows down noticeably. I haven't solved this yet — but it's on the table. If anyone has dealt with high-volume terminal output in C++ and has ideas, I'm genuinely open to them. Drop a comment or open issue #3 on GitHub.
Hoping to have copy ready before the end of the week.
github.com/TheNobelVoid/kron
Top comments (0)