GNU stow is another one of those projects that took me a while to wrap my head around, but once I saw it in action, it made perfect sense. Of course, given that stow doesn’t really show any output, that statement is ironic on another level.
As I understand it, stow is intended as a kind of package manager for software you might build locally — which in my case, is quite a lot. stow works by creating symlinks from a program’s original location to a central depot of your creation.
The idea is that this reduces the chances of unforeseen conflicts, and makes managing random, scattered files easier, since most everything is in the same place. One program, one folder, and appropriate symlinks elsewhere in the system.
If that doesn’t make a lot of sense, don’t worry, because two hours before I wrote this, I was trying to wrap my head around it too. Now though, I think I see the value in it.
What clued me in was this post by Brandon Invergo, where he talks about creating a folder specifically for dotfiles with stow. Brandon is an easy read and he gives you a good visual illustration, so don’t worry if you’re not a fan of reading from blogs. Neither am I (ironic, isn’t it?).
If you step through his post, you’ll end up with a small tree of folders with the dotfiles of each program nested individually. Your home folder will still hold links to those files, and everything will still work as it should. So don’t panic. 😉
I tested it with two programs that I thought more or less bulletproof, even if my configurations were utterly vaporized: htop and snownews. And after Brandon’s instructions, wouldn’t you know it, everything worked fine.
Why would I want to do this? Well, like Brandon explains, this makes it much cleaner to synchronize your dotfiles against an online repository — for example, you can more conveniently dump your dotfiles on github. No more cherrypicking files and sending them singly.
But personally, I usually have a lump of folders and settings that I transfer between machines, to expedite setup or testing. Even just in the past two or three days, I’ve ended up manually copying files from one machine to another, and from that machine to a third. In the future, I expect I can install stow, rsync the dotfiles folder to the new machine and jump right in.
I suppose you could do this manually, file by file and link by link, and not need stow. But just thinking about that should make it obvious why stow is a good tool: Manually setting up all those links would be tedious to say the least.
I have the reassurance of Brandon and some other sites that even if you uninstall stow, your link systems will continue to work. That makes sense to me, even if I haven’t taken that step yet.
stow has the potential to be a game changer for you, if you need that kind of added flexibility with packages or with your personal configuration files. It won’t clean up your home directory — you’ll end up with just as many symlinks as you had configuration files, and in the same place — but it adds a layer of convenience that you might find immediately attractive.
Stow is great! I have been using it for working with my dotfiles, since there were too many “real” dotfile-managers and I missed the obvious. In Debian there is also a package called “xstow”, but that one is written in C++, not in Perl. – The only stupid thing I have noticed so far: there are files like “.forward”, which cannot be set as symlinks…
Pingback: toast: Challenging my spongy pink organic brain | Inconsolation
There is even easier alternative to stow, and it is interestingly named ‘dotfiles’! Check it out here,
Thanks, I will have a look at it!
Pingback: toast: Challenging my spongy pink organic brain | Linux Admins
Pingback: Bonus: 2014 in review | Inconsolation
There’s another tool like stow, but even cleaner and easier to use, called Dotbot:
You’re right, and I believe dotbot is intended specifically for remote dotfile caching, while stow arguably does it as an afterthought. Thanks!