rcm - rc files manager: tuning and use

  • Tutorial

Prehistory


When more than one working device appears in your hands, then,%% username%, you will want to have the same configuration here and there, at work, and at home. When I just started trying to synchronize files, Dropbox and Yandex.disk were enough for me. They helped to synchronize documents and the history of the jabber especially well, but as soon as I tried to adapt them to .bashrc, .vimrc and the like, they immediately began to emit various side effects. For example, with symlinkes in both systems, the utmost misfortune, ± some kind of history is only in the dropbox, and you would have to write the zoo management scripts yourself. Surely something has already been written,true?


Story


On the page https://dotfiles.github.io/ there are a little less than a hundred different utilities, plug-ins and approaches to configuration management, ranging from customized programs to universal ones. I strongly advise you to read, it is possible that you stop further reading and go to choose something more acceptable.


The general meaning of philosophy comes down to the fact that configs lie in the% your_favorit_vcs% repository in a certain form and then crawl away from there $HOME. Since% default_vcs% is now git, I will use it later.


I started my acquaintance with dotfiles-in-git with a utility called dotgit . It began as "simple and clear on a clean bash." But at the moment when the author added encryption there with the ability to make symlinks directly to the directories, and I tried to figure it out (about the beginning of 2017), my home folder had a brain cucumber with broken links and manual file recovery from the git. In general, one day was allocated to search for alternatives with the possibility of tuning behavior and simple configuration.


rcm


So, as already mentioned, there are, indeed, many options for utilities. rcm was chosen for the following reasons:


  • Pure sh, not even bash. It pulls neither python, nor ruby, anything else.
  • Allows configuring configs delivery behavior
  • Availability of man pages
  • Customization Deploy with folders tag-*andhost-*
  • Long support, lively developing project
  • At the time of use, it is not relevant to this day, but {pre,post}-{up,down}hooks for updating and cleaning configuration files are supported.

The most important point is, of course, the documentation, because without it I would not have come to fully customize the behavior of the deployment for myself.


After installing the manager, 4 commands will be available:


  • lsrc - displays a list of how the configuration will look after execution rcup.
  • mkrc - adds the file to ~/.dotfiles(by default, you can change to ~/.rcrc) and then installs them back. If non-standard behavior is necessary, it is better to correct it first ~/.rcrc, otherwise there may be unexpected special effects.
  • rcdn - deletes all configuration files managed by rcm.
  • rcup - installs all files. If a parameter is used -g, a separate shell script will be generated, which can also be put in the repository for use on hosts where the manager is not installed.

As such, the file ~/.rcrcis simply part of a shell script that the command connects sourcewith each invocation of the rcm utilities. On this basis, it can be made modular, with integrated logic. According to the documentation, its contents allow for fine-tuning of the settings of the installation of dotfiles using rcup, for example:


  • The default behavior: on every file inside ~/.dotfilescreates a symbolic link in the home directory without the starting point (for example '/home/felixoid/.dotfiles/bashrc' -> '/home/felixoid/.bashrc', '/home/felixoid/.dotfiles/README.md' -> '/home/felixoid/.README.md')
  • Daddy ~/.vim: is a symlink to a folder /home/felixoid/.dotfiles/vim(option SYMLINK_DIRS)
  • daddy ~/.some_secret_files: copied from /home/felixoid/.dotfiles/tag-dmz/some_secret_files(option COPY_ALWAYS)
  • the file ~/.README.mdis actually ignored (EXCLUDES option)
  • file '/home/felixoid/.zshenv'is a symlink on '/home/felixoid/.dotfiles/tag-zsh/zshenv'(parameter TAGS)
  • the folder is ~/binalso controlled by rcm, its contents come from /home/felixoid/.dotfiles/bin/(parameter UNDOTTED)

Sometimes it may be necessary to mention the same file in several options. For example, a snippet .rcrc should look like this, if all the content ~/binshould be in ~/.dotfiles/tag-bins/binand copied as is:


COPY_ALWAYS="bin/*"
TAGS="bins"
UNDOTTED="bin"

Actually, an example of how to organize the contents of a folder ~/.dotfilesis in the repository with dotfiles. Exhaustive information is contained in the documentation, feel free to read the following man pages: lsrc (1), mkrc (1), rcrc (5) rcdn (1), rcm (7), rcup (1).


Untold and undelivered


While I was typing this text, I received some good ideas about how to organize the storage of sensitive data within the public repository. For example, I was always worried about the question, does it make sense and is it possible to make backups of gpg and ssh keys? Hooks might be useful for this: pack them into tar, then encrypt with the same symmetrical gpg and then unpack it. Perhaps I will dedicate this to the following note after implementation. Or maybe this is another bike? And everything is already invented? Add in the comments if this is actually the case.


I really hope that this material will cause interest and desire to try to organize the management of configs in semi-automatic mode!


And a small survey:

Only registered users can participate in the survey. Sign in , please.

Do you use any manager for dotfiles?


Also popular now: