Overview
This is the first pre-release of the CLI tool called syedm, which is my lightweight dotfile manager. It’s a symlink-based dotfile manager, which, in my case, means it symlinks your dotfiles from your repo to the appropriate directories on your system. It is written entirely from scratch in C(23) with NO external dependencies. Below you can find explanations of each feature and what it does.
Features
Custom CLI argument parser
As you would imagine, a CLI tool needs a CLI argument parser. I built mine completely from scratch, and currently it supports:
- short flags (e.g.
-n)
- long flags (e.g.
--dry-run)
- combining short flags (e.g.
-ni)
- value flags (e.g.
--install .)
There is a built in help flag, which displays all the options, whether they take a value and a short description (see image).
Installing dotfiles
Installing dotfiles is straightforward. First, your dotfiles repo must match the structure outlined in README.md (here). Then, if you are in the root of your dotfiles repo, simply run syedm -i . and that will install your dotfiles from your current directory to the directories based on the mapping. You can change these defaults by passing the appropriate flags with the appropriate paths.
By default, syedm WON’T overwrite files that already exist on the location(s) it tries to install your dotfiles to.
Dry-run (preview of changes)
A really helpful feature that I’m pleased is part of my project is the option -n, --dry-run. It shows what WOULD happen if you were to, for example, install your dotfiles. This is really helpful as you can preview what the tool would do. For example, running syedm -ni . will preview what the tool would do while installing. It also works on a couple of other flags.
Force
If you wanna overwrite files that exist at locations syedm wants to install to, simply pass the -f, --force flag while installing.
Status
If you wanna check the status of your dotfiles, you can run syedm -s . and that will print the status. Some status options include MISSING (not installed) or IS_DIR (destination is a directory). For a full list of the output, please consult the appropriate entry in README.md, that can be found here.
Logging
The project uses a custom logger I built, which logs into stdout with great detail. Logs include the source file and line of the log, colored severity (DEBUG, WARN, etc.) and the actual info. This is a neat feature that ensures errors can be easily traces and debugged.
Internals
If you are curious, I have implemented, for this project, a kind of OOP in C. I use opaque pointers in structs to hide away the “private” members, ensuring you can’t directly access/modify the members. You can only get/set these via dedicated getters/setters. I have also made the structs use the singleton pattern by holding the instance of the struct in a static thread-local variable, which makes it so you can have a very nice clean syntax, such as logger->SetColor(..) without having to pass the struct in the function. The structs contain function pointers, ensuring you can use familiar OOP-like syntax (e.g. cli->CliParse(...). I believe this really sets my project apart as this is a fairly advanced C concept.
Conclusion
I personally use this tool to manage my own dotfiles, as I had built it specifically to fit my use cases. It is quite primitive, and I do plan to expand it, but right now it does all it needs. If you have feedback about anything, including new features, improvements, bugs, PLEASE let me know and I’ll make sure to fix them. Thanks for reading this!
