If you add more features, like store the settings in a sqlite, universal config r/w interface, and live config change notification to apps, you'll come up with a system like Registry.
Using GNU Stow to manage your dotfiles
11–20 of 73 posts
Re: Using GNU Stow to manage your dotfiles
#12I use a similar method, but structured around a single Makefile: https://github.com/staticshock/seashell
This lets me perform any necessary initialization (e.g. cloning submodules) via `make` and installing the actual symlinks into $HOME via `make install`.
Re: Using GNU Stow to manage your dotfiles
#13I would really like to have a dotfile strategy. But I have another goal beyond synchronization: I would like to be able to organize my dotfiles in a modular fashion.
For example, I would like to construct my bashrc using something like run-parts. This system would take bash/★.bashrc, this-machine/local-env.bashrc, and special-app/proxy-env.bashrc and compile them into a single ~/.bashrc. I would also like to be able to build a ~/.nanorc that only includes features supported by the installed version of nano. Some dotfiles include both public and private data -- I'd like to publish my git aliases, but not my GitHub authentication token.
So I basically want a dotfile manager that's a combination of PHP, run-parts, and stow: dotfiles constructed through in-line Perl code (in my nanorc or ssh_config) with assembly of multiple pieces (in my bashrc or gitconfig) and installed into the right place in my home directory.
As far as I can tell there's nothing out there that can do this. (Although I also insist it be written in something classic that I can find anywhere, like Python 2.4 or Perl or something like that. So I didn't look at any of the many dotfile managers written in Ruby or Node.)
set const
set cut
2 || $NANO_VER[1] >= 1 ) { # Assume nano 1.x isn't still an issue
?>
bind M-f nextword main
bind M-b prevword main
;
# Maybe I'll have to write this myself....
?>Re: Using GNU Stow to manage your dotfiles
#14If you add more features, like store the settings in a sqlite, universal config r/w interface, and live config change notification to apps, you'll come up with a system like Registry.
The difference is that dotfiles are simple, text based, and human readable.
When you re-install a Windows system, do you overwrite the registery with a backup you had? I doubt it.
Re: Using GNU Stow to manage your dotfiles
#15but 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 I totally disagree. I love having much of my home directory in git. I have a .gitiignore for the stuff I don't want in there, but the rest. Ahhhhh, so nice to be able to clone somewhere else and use.
I also keep my whole homedir in git, and it's great. My approach isn't to .gitignore, because I want to ignore almost everything -- I just add and commit things when I want to track them. One of my many git aliases[1] is 'git sn' for showing status without untracked files; this helps when dealing with my homedir: status --short --branch --untracked=no [1] https://github.com/cespare/dotfiles/blob/master/.gitconfig#L..…
I actually prefer to .gitignore things explicitly, because then any new dotfiles show up in "git status" until I explicitly disposition them.
Re: Using GNU Stow to manage your dotfiles
#16ln -s ~/dotfiles/.bashrc ~/.bashrc
Re: Using GNU Stow to manage your dotfiles
#17I use Vcsh. It allows for more than one repository. It's a Shell script, uses Git and it doesn't symlink.
Re: Using GNU Stow to manage your dotfiles
#18I would really like to have a dotfile strategy. But I have another goal beyond synchronization: I would like to be able to organize my dotfiles in a modular fashion. For example, I would like to construct my bashrc using something like run-parts. This system would take bash/★.bashrc, this-machine/local-env.bashrc, and special-app/proxy-env.bashrc and compile them into a single ~/.bashrc. I would also like to be able…
Hi,
My dotstuff script can do most of that, with a little bit of work. With the current features, you'd put all your bashrc content into a single ~/dotstuff/bashrc file, marked off with preprocessor directives that turned on and off certain sections depending on the content of the "environment" (a simple key-value file).
Adding the ability to query the version of installed software would be easy to add. Adding the ability to concatenate multiple files would be fairly easy too. Although I think an "include" directive might make more sense than run-parts style, since many dotfiles have hierarchical structure.
It's written in 2.4-compatible Python and I'm happy to accept contributions.
Re: Using GNU Stow to manage your dotfiles
#19but 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 I totally disagree. I love having much of my home directory in git. I have a .gitiignore for the stuff I don't want in there, but the rest. Ahhhhh, so nice to be able to clone somewhere else and use.
I take a similar approach. I have a dotfiles git repo in ~/dotfiles/ and have a Makefile which creates symlinks in my home directory. For example, ~/.bashrc is a symlink to ~/dotfiles/bashrc. That way, I can have a whitelist (whatever's in the Makefile) instead of a blacklist (like a .gitignore).
The fake bare approach might be easier: http://mjollnir.org/blog/migrating-my-homedirectory-from-one...
Re: Using GNU Stow to manage your dotfiles
#20The primary complaint of the article is tools that manage the files in git and symlink things into place have lots of dependencies.
ghar, a project I wrote, is a single standalone python file: https://github.com/philips/ghar