Managing dotfiles with GNU stow

[alexpearce]

Comment thread for post Managing dotfiles with GNU stow.

Comments made before 18 February 2021 were imported from Disqus using an import script. The datetimes and authors of the imported comments do not reflect the values of the original comments.

[alexpearce]

Comment № 1 originally by Fabian B at 2017-02-27 23:40:33 UTC.

If i done all this and want to replicate my dotfiles on a second computer, what commands do i have to type in?

[alexpearce]

Comment № 2 originally by Alex Pearce at 2017-02-28 08:32:49 UTC, replying to a comment by Fabian B at 2017-02-27 23:40:33 UTC.

There are many ways you can transfer files between two computers, and your collection of dotfiles is nothing special in that sense.

I do this by putting my dotfiles in a GitHub repository, so that I can just clone the repository on other machines.

[alexpearce]

Comment № 3 originally by Fabian B at 2017-02-28 09:46:48 UTC, replying to a comment by Alex Pearce at 2017-02-28 08:32:49 UTC.

Okay then i got the files all in one git folder and then simply call stow on that folder and all dotfiles will be symlinked automatically on the other machine?

[alexpearce]

Comment № 4 originally by Alex Pearce at 2017-02-28 10:07:43 UTC, replying to a comment by Fabian B at 2017-02-28 09:46:48 UTC.

Ah, now I understand. You want to 'deploy' the sym-linked to a remote machine.

I haven't done this. An easy option is to copy the whole folder (in ~/.dotfiles or something), and then execute stow on the remote machine (where you'll need to install stow).

[alexpearce]

Comment № 5 originally by cig0 at 2017-12-20 01:28:18 UTC.

I'm all about publicly sharing configurations that might be helpful for someone else or, who knows, maybe the source of inspiration -- like all the time happens to me.
However there are serious security implications that should be taken into account before using a public repo, i.e. upload sensible stuff that you definitely don't want to share with anyone else.

To play safe, take a look at Keybase: they 'recently' added Git repository management, making an already cool solution even more cooler!

[alexpearce]

Comment № 6 originally by Alex Pearce at 2017-12-20 09:04:03 UTC, replying to a comment by cig0 at 2017-12-20 01:28:18 UTC.

I've heard about that but don't know much about it. A git repository on Keybase is like having a private repo on GitHub, I guess? But the repo is encrypted on Keybase's servers, and only you have the private key?

[alexpearce]

Comment № 7 originally by Alex Pearce at 2019-10-07 20:32:34 UTC, replying to a since-deleted comment.

Stow creates links named as the contents of the folder foo1.3. So, if the contents is a single file foo1.3/bin/foo, stow will create the symbolic link ../bin/foo.

[alexpearce]

Comment № 8 originally by Managed Kaos at 2020-04-17 19:17:38 UTC, replying to a comment by Alex Pearce at 2019-10-07 20:32:34 UTC.

I think the confusion is in this section:

$ mv /usr/local/bin/foo1.3 foo1.3/bin
$ mv /usr/local/bin/foo2.0 foo2.0/bin

It should most likely be:

$ mv /usr/local/bin/foo1.3 foo1.3/bin/foo
$ mv /usr/local/bin/foo2.0 foo2.0/bin/foo

Note the missing 'foo' on the end of the second path.

[alexpearce]

Comment № 9 originally by Alex Pearce at 2020-04-19 15:49:05 UTC, replying to a comment by Managed Kaos at 2020-04-17 19:17:38 UTC.

Yes! You're quite right, thanks a lot for the pointer. It's now fixed.

[alexpearce]

Comment № 10 originally by Fredrik Mellström at 2020-08-14 05:50:12 UTC.

I think you should also mention that since stow version 2.3.0, there is an option --dotfiles, which enables you to have better filenames inside your repository. You can call your files dot-bashrc, dot-bash_profile, dot-vimrc, and so on. The leading "dot-" will be renamed to "." by stow when using this option. :-)

[alexpearce]

Comment № 11 originally by Alex Pearce at 2020-08-15 07:00:14 UTC, replying to a comment by Fredrik Mellström at 2020-08-14 05:50:12 UTC.

Looks like a great feature, thanks for the pointer!

I gave it a quick go, but it doesn't work with directories yet. A lot of my dotfiles are for .config directories, so I will hold off using --dotfiles for now.

[codePassion-dot]

I'm new using stow so I could definetly be wrong on this one, but as far as I understand we have three things A -> target directory, B-> stow directory (A is parent folder of B) and C the things we are stowing which are inside of B. in your example /usr/local/bin is A, /usr/local/bin/stow is B, and foo.1.3 is the thing you are stowing (C), so stow by default will put the symlink one folder above the stow directory (B). i.e /usr/local/bin (A). So according to this if I'm not missing something it should be mkdir /usr/local/bin/stow instead of mkdir /usr/local/stow @alexpearce otherwise your symlinks will live on /usr/local not /usr/local/bin

[alexpearce]

@codePassion-dot You're absolutely right that if we created a file as /usr/local/stow/thing/x then stow thing would be symlinked to /usr/local/x.

Note however that we create subfolders under thing, and stow respects this structure when creating links in the parent directory.

So /usr/local/stow/thing/bin/x, with the additional bin/ subdirectory, would be symlinked to /usr/local/bin/x.

This is helpful because our thing might need to expose stuff not only under bin/ but also under lib/ or share/ example. So by placing the Stow directory at /usr/local we can have Stow create such directories for us (if they do not already exist).