![]() Invoking a zsh terminal now works as expected. We can now deploy the stow we have created for zsh using: $ stow -d ~ /config -t ~ zsh In our example, the directory where the stow is located would be ~/config, and the target directory would be ~. To deploy a stow we need to know where it is located (option -d or -dir), and which target base-directory you’d like the symlink-tree to be built on (option -t or -target). To activate (i.e., symlink) the config, the stow needs to be deployed. We have now created our stow for zsh in ~/config/zsh! However, if you try to open a zsh terminal, your configuration will obviously be missing. $ mkdir -p ~ /config/zsh $ cp ~ /.zshrc ~ /.zshrc.backup $ mv ~ /.zshrc ~ /config/zsh 2. Note that you might want to make a backup if you’re following along. To stow your zsh configuration (a unit), you create a directory for it (say, ~/config/zsh) and move all your configuration (in this example, the file ~/.zshrc) inside this directory - taking care to preserve the relative directory-tree. A simple and mostly sufficient approach is to use a ~/.zshrc file with all the aliases, environment variables and all sorts of voodoo you’d want in your terminal prompt. I will use a typical scenario: configuring zsh. This is best illustrated using an example. The file-structure within each unit can then be symlinked to a different base-directory in the filesystem. Stow stores configurations in units, and each unit is stored in a separate directory. There are many articles which describe how to use stow for this purpose, and here, I will only give a very quick and cursory overview of how I personally employ it. ![]() While stow obviously has a number of important use-cases (it was not developed to manage dotfiles), its ability to seamlessly mount and unmount entire symlink hierarchies makes it an excellent tool for config management. stow is an old, old (at least older than 2001) utility used to manage “symlink farms”, i.e., it specialises in keeping track of large symbolically linked directory structures. I have been using stow for almost 3 years now, and, combined with git, it is easily the most straightforward way to deal with configuration management I have experimented with. I obviously like to maintain a well documented and tractable system configuration, but the pressures of day-to-day life often end up pushing it very low down my priority list. It is a serious tool, and it required me to make a 24/7 commitment to config tractability - something that I am starting to believe myself incapable of. While I found chezmoi to offer more options than I will ever need, I found its interface to be demanding. After about 6 months of use, I realised that chezmoi was exactly what it says on the tin - a no nonsense, highly specialised tool for complete and total config control. One of the most successful and comprehensive dotfile management tools in use today is chezmoi - and after browsing through articles written by serious programmers with needs far beyond my own, this is what I moved to next. Thus, most configuration management tools often have names like dotbot and dotdrop. In Linux, configurations are usually stored as dotfiles - i.e., files with names starting with a dot (e.g. Searching for an alternative, I realised that there are, in fact, a number of actively developed, open-source tools for configuration management. While the system worked well, it was cumbersome, and involved remembering a lot of intermediate steps any time I wanted to edit a config file. And this is exactly how I started, many many moons ago. ![]() A rather elegant and nifty method first (as far as I can tell) documented by Nicola Paolucci in this article, is to use bare git repositories. Using gitĪ natural approach to managing your config is to employ some sort of a version-control system like git. Keeping track of your configuration allows you to re-use a well written config, to go back to a working configuration when things go awry, and to move safely and methodically between systems. These can be configs for specific software, for processes and services, or for individual environments and contexts. Sooner or later, every linux-user has to deal with keeping track of configurations (configs).
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |