it's been said of every console user: "you are your dotfiles".

i manage mine with gnu stow, a free, portable, lightweight symlink farm manager. this allows me to keep a versioned directory of all my config files that are virtually linked into place via a single command. this makes sharing these files among many users (root) and computers super simple. and does not clutter your home directory with version control files.

installing
stow is available for all gnu/linux and most other unix like distributions via your package manager.


how it works
by default the stow command will create symlinks for files in the parent directory of where you execute the command. so my dotfiles setup assumes this repo is located in the root of your home directory ~/dotfiles. and all stow commands should be executed in that directory. otherwise you'll need to use the -d flag with the repo directory location.

the rest of this article will directly corrilate to my dotfiles, they're available here: http://git.io/.files

to install most of my configs you execute the stow command with the folder name as the only argument.

to install herbstluft theme use the command:


this will symlink files to ~/.config/herbstluftwm and various other places. (note the folder structure on the herbstluftwm directory)

but you can override the default behavior and symlink files to another location with the -t (target) argument flag.

to install the ryu-login you need to execute the command:


this will symlink the file to /etc/issue.

note: stow can only create a symlink if a config file does not already exist. if a default file was created upon program installation you must delete it first before you can install a new one with stow. this does not apply to directories, only files.

tl;dr
navigate to your home directory


clone the repo:


enter the dotfiles directory


install the zsh settings


install the root zsh settings


install awesomewm theme


uninstall awesome theme


install herbstluftwm


i hope this gives you some ideas for managing your own dotfiles!

That looks nice, thanks for making the tutorial.

Nice howto ! That's the type of content that would fit nicely in the diary

I know I sound like a dick; but why not Git or CVS?

git : version your dotfiles, save them online, as well as previous copies.
stow: symlink file manager, you can see it as a smart way to deploy your versionned dotfiles

so basically:


(I don't know the syntax or whatsover, just explaining how you could use it)

you got it z3bra! i keep my dotfile in a git repo (http://git.io/.files) then *IN* that repo i use the stow command to link the files into place. it keeps your home directory cleaner (no version control files in the root) and all the dotfiles in one place. so when i make changes to say my zsh aliases, i don't have to copy the file into the repo. i just update the file in the repo and the symlink makes the change virtually in place.

Oh that actually does make sense. Might check it out soon, thanks xero!

This guide just brought my dotfiles set-up to a much better place.

Long time GNU Stow user here, and have been recently working on a simpler replacement called sym. source is here and some rationale and usage can be found in the readme. It requires python 3.6+, stdlib only, and am planning on using it as a reference implementation for a rewrite in some compiled language in the future when I have more time.

Let me know what you guys think. I migrated my dotfiles installation to it like this, main benefits being:

• you can specify more than one source directory so as to invoke the tool only once, as opposed to stow multiple times
  
• a cleaner default command line invocation (e.g.
  
• source directory location can be arbitrary and not limited to 1 directory level (stow will complain about "slashes not permitted in package names")
  
• better cleanup (will remove empty dirs resulting from symlink removal)
  
• 100-ish LoC, clean and readable
  

There's one feature I'll be adding soon - the ability to specify repeatable --include and --exclude glob patterns (or, probably regexes) to compliment the default blacklist. If there are any other feature requests or criticisms, do let me know, but regarding the former I'd like to keep sym as simple as possible for the use case at hand.

I just use a single shell script. I'm a basic bitch I guess.

If that works for you, you shouldn't feel bad about it :)

this post was about my personal workflow and what works for me. ricing and beaning is all about your own personal workflows. i intended this post as a thought experiment more than a "you should do this with your dotfiles" type post.

tbh, on some remote machines when i just need a single apps dots i'll do something like:

I used to use stow as well, but I have since switched to a simpler thing: I keep all my dotfiles in ~, but they are version-controlled in ~/etc through a bare git repo:


It has worked really well so far. As a bonus, it plays nicely with vim8 (which has a built-in plugin manager), as I can just run

I use a custom zdotdir to wrangle all my dots into one $XDG_CONFIG_HOME, which is a repo using a gitignore with * in it. i git clone once, and never link anything and am good to go. It's really the nicest I've ever had.

2014 seems like yesterday.

Quote:it's been said of every console user: "you are your dotfiles".

But it's also been said that dotfiles are a big mistake. What should we make out of all this.

They say that everything in life is so that we avoid pain. And so time management, and thus dotfile management, is pain management. Do you agree?
Do you also use a software to help you manage your dotfiles, share your story.

I keep my dotfiles (or, rather, config files) synched with one of my servers, but I honestly have no idea which ones I even have. :-)

I only actively “manage” those which made me spend enough effort, like Emacs and dwm. Those which work OOTB are irrelevant.

I think managing dotfiles is adding complexity and pain to an environment.

The less configuration files I have, the better I am.

Now you sometimes need dotfiles, so for these special cases, I try my best to keep is short enough, so that rewriting it entirely is faster than pulling dotfiles from a remote server.

For the longest time I used git to track $HOME (ignoring *) and then just $HOME/.config, and then decided that the easiest and least headache-inducing (for my use case) was to just.... not. Now I rsync $HOME every evening to a NAS (ignoring a couple of "temp" folders i.e. Downloads), and try not to make any big mistakes when updating configs!

However, I think the basic git repo in /etc (ignoring *) is still nice 'n' easy for remote servers and the like where I make much fewer changes but want backups.

(14-09-2020, 08:15 AM)z3bra Wrote: The less configuration files I have, the better I am.

It is quite nice to go through the folders in $HOME and have a big purge of config/cache files.

(14-09-2020, 08:15 AM)z3bra Wrote: The less configuration files I have, the better I am.

Could not agree more. With text editors I usually just configure the cosmetic stuff and my .cwmrc is so simple I can easily rewrite it from memory. If my hard drive was magically wiped tomorrow, it wouldn't take me long to setup an enviroment that I could get stuff done with.

(14-09-2020, 08:15 AM)z3bra Wrote: I think managing dotfiles is adding complexity and pain to an environment.

The less configuration files I have, the better I am.

Now you sometimes need dotfiles, so for these special cases, I try my best to keep is short enough, so that rewriting it entirely is faster than pulling dotfiles from a remote server.

I'm with z3bra here.

With time I am moving from programs with involved configuration files to programs configurable via environment variables, X resources (for X programs) or command-line arguments. Thus, I only have to change my .profile (or .Xresources) and set the appropriate variables, or create a wrapper script calling the program with the correct command-line arguments.

Or, in the last case, I use programs configurable at compile time via config.h (but most of the time, in those cases, I change the source for the program to read environment variables so I can change its configuration at runtime).

Only programs with a really complex interface or that should read a database for being usable that I accept as having a rules file. In those cases, I move their rules files from ~/.* or ~/.config/* to ~/rules/* (I call they “rules files” rather than “configuration files”).

(14-09-2020, 08:15 AM)z3bra Wrote: I think managing dotfiles is adding complexity and pain to an environment.

I'm growing strangely fond of the suckless folks' approach using a config.h to compile configuration settings directly into their programs. I like to compile most of the stuff I use anyway and wish more of it would support this approach. (And config.mk rather than ./configure !)

The configuration strategy used is definitely a criterion that should be included when deciding between software alternatives.

Maybe I'm a little conservative about what to pull into my environment, but I'm definitely invested in conforming all the configuration files in my environment to have the same bindings and color scheme. To such an extent that some of my dotfiles run on a template system[0] (I've since seen many do this, even if just through pywal) to be able to change global colors in a single place.

When I initially wrote such a system, I thought I would be reloading themes all the time[1]! How wrong I was -- in the past few years I've settled into one theme and refine as my tastes develop. But it's still nice to be able to enact these changes from a central location. Naturally I pay for this with a complexity cost, including hosting "rendered" dotfiles[2].

----

I don't want to care about how a program is configured, as long as I CAN configure it, and it's worth doing so. And if it is, the magic of open source allows me to bridge to it however I like (via scripts/templates), and then I can forget about it.

----

Tying into the OP of this thread, I created a stow clone called stOwO [3] which has the luxury of assuming the dotfiles repo location, and doesn't create directory level symlinks like stow does. It's been OK so far.

[0] see the readme: http://noriceno.life
[1] https://www.reddit.com/r/unixporn/commen...yesterday/
[2] https://github.com/neeasade/dotfiles/tre...s/rendered
[3] https://github.com/neeasade/dotfiles/blo.../bin/stowo

(16-09-2020, 01:07 PM)neeasade Wrote: When I initially wrote such a system, I thought I would be reloading themes all the time[1]! How wrong I was -- in the past few years I've settled into one theme and refine as my tastes develop.

ooh boy, I wrote something kinda automated for my own system (basically sed-ing an "include" line in ~/.Xresources to change the theme) with the idea I could change theme all the time. Truth be told, I basically never change it.