Live data from Hacker News

Using GNU Stow to manage your dotfiles

brandon.invergo.net

41–50 of 69 posts

Re: Using GNU Stow to manage your dotfiles

#41
post #26

I maintain environments on Windows (Cygwin), Linux, OS X and Solaris machines. Some of these are work, some are home. Not all files overlap. Additionally, I have scripts that are only relevant when I have a certain program installed, or a certain source tree available. I ended up spending a weekend writing my own system that composed a PATH, .bashrc, .bash_profile etc. based on machine configuration. A single git clo…

see jackalope's helpful comment -- https://news.ycombinator.com/item?id=8488828

Re: Using GNU Stow to manage your dotfiles

#42
post #9

This makes no sense. Somehow having a versioned dotfiles directory with either a Makefile or a shell script is "hard" because either you need to have Python (no you don't, shell script is fine) or you forget the name of the install script (type ls), but somehow using this software (which needs to be installed) is "easier". With this software you also need to remember the magic invocation, a trivial thing in both scen…

This use case is one of the expressed reasons for stow's existence. "GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place. This is particularly useful [to] facilitate a more controlled approach to management of configuration files in the user's home directory, especially when…

You literally type make and you're done too.

Re: Using GNU Stow to manage your dotfiles

#43

> but many/most dotfiles reside at the top-level of your home directory, where it wouldn't be a good idea to initialize a VCS repository. Right. Which is why I use git with a workspace detached from the git directory. The git directory is in ~/dotfiles/.git, with "git config core.worktree ~", and I set an alias "dgit=git --git-dir ~/dotfiles/.git". The advantage of this method is that there are no symlinks to maintai…

The one thing I like about stow is that I can choose to only add configurations that make sense for the machine I am using. If don't have a certain application, I don't 'stow' the configuration for that application in my home directory.

I used to have complex configuration files that worked in all scenarios using conditionals and detecting available features, but now I just generate the configuration files, or rather specialise the parametric versions of them, and push them with chef/cfengine/ansible or even rsync.

Re: Using GNU Stow to manage your dotfiles

#44
post #34

Earlier quoted context omitted.

Yeah, the git in the bash prompt thing was the most annoying thing to me, honestly :) Since there is interest, I'll elaborate on the understated "a bit painful" part of moving the files after an initial clone which leaves the files in the ~/dotfiles dir. The problem is that I didn't find an easy "move and overwrite recursively" command in Linux. Here's the magic command from my script: git ls-files --cached -z | rsyn…

I have very similar setup to yours, but my solution is to use a bare repository. To set up dotfiles on a new computer is just $ git clone --bare git@github.com:mbudde/homedir.git .homegit $ git --git-dir=.homegit --work-tree=~ checkout -f # Overwrite existing files $ echo '*' >> .homegit/info/exclude And then I have a simple git wrapper script [1]. I moved from using an alias to a script for some reason I can't remem…

This definitely looks like a better alternative!

Re: Using GNU Stow to manage your dotfiles

#45
post #10

Earlier quoted context omitted.

This is great! It fixes the only problem I have with maintaining my dotfiles as a git repo: the .git dir in ~. That interferes with so many things such as the CtrlP vim plugin, the integration of git with the bash prompt and many other things. Thank you for this.

Yeah, the git in the bash prompt thing was the most annoying thing to me, honestly :) Since there is interest, I'll elaborate on the understated "a bit painful" part of moving the files after an initial clone which leaves the files in the ~/dotfiles dir. The problem is that I didn't find an easy "move and overwrite recursively" command in Linux. Here's the magic command from my script: git ls-files --cached -z | rsyn…

> I didn't find an easy "move and overwrite recursively" command in Linux.

You don't need recursiveness into commands, just use find (maybe with xargs) to generate the list of files to overwrite (or commands to execute).

Re: Using GNU Stow to manage your dotfiles

#46
post #11

This is how I manage my dotfiles since I discovered stow a couple of months ago. The only thing that bugs me is that I haven't figured out an elegant way to have some configs include machine specific configs. For example a set of bash aliases that I only use at work but don't want at home. My best idea is to source all files in, say ~/.bashrc.d and put machine specific configs in there... Haven't tried it out yet.

> My best idea is to source all files in, say ~/.bashrc.d and put machine specific configs in there... Haven't tried it out yet.

A fair amount of the time when I'm setting up a .foorc, I'll want to add some functions to bashrc, or change a MANPATH or something, so this pattern is useful for that too; you could just have a ~/dotfiles/.bashrc.d/foo.sh and have your .bashrc unconditionally source everything in ~/.bashrc.d/. Then when you use stow to setup foo, its bashrc modifications get installed too.

Re: Using GNU Stow to manage your dotfiles

#47
post #45

Earlier quoted context omitted.

Yeah, the git in the bash prompt thing was the most annoying thing to me, honestly :) Since there is interest, I'll elaborate on the understated "a bit painful" part of moving the files after an initial clone which leaves the files in the ~/dotfiles dir. The problem is that I didn't find an easy "move and overwrite recursively" command in Linux. Here's the magic command from my script: git ls-files --cached -z | rsyn…

> I didn't find an easy "move and overwrite recursively" command in Linux. You don't need recursiveness into commands, just use find (maybe with xargs) to generate the list of files to overwrite (or commands to execute).

That's what I did in my first iteration, except find is hell.

No wait, I mean find is a really powerful and sophisticated tool, but it takes time and effort to get it to do precisely what you want. It turned out rsync did what I wanted more easily.

Re: Using GNU Stow to manage your dotfiles

#49
post #45

Earlier quoted context omitted.

> I didn't find an easy "move and overwrite recursively" command in Linux. You don't need recursiveness into commands, just use find (maybe with xargs) to generate the list of files to overwrite (or commands to execute).

That's what I did in my first iteration, except find is hell. No wait, I mean find is a really powerful and sophisticated tool, but it takes time and effort to get it to do precisely what you want. It turned out rsync did what I wanted more easily.

Find has an atrocious syntax. Nowadays, I seldom use any other feature of find rather than just enumerating files. Rather, I enumerate files, create commands on them (with things like xargs and sed), and pipe the output into sh. Generating code is a very flexible technique, and it's actually easier (and safer) that trying to muck with find options.

Re: Using GNU Stow to manage your dotfiles

#50
post #39

What I do is just keep all of the dotfiles in ~/dotfiles and symlink them to the home directory, then I can keep track of them with git. Doesn't have to be any more work than that. Maybe it's not an issue for me because I only use one machine, and when I switch to another, I just pull down my dotfiles from github and symlink them again. I only do this every couple years.

This is what I do as well, and I also have a little script that creates all the symlinks in my home directory as well. Dead simple, and it works. I was hoping Stow would somehow be an improvement over that but I don't really see how it does anything more for you.
Post reply on HN