Skip to content

tifrueh/dotfiles

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

531 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

My Dotfiles

These are my dotfiles, i.e. configurations for all sorts of stuff. They are mainly here for my own usage, so if you want to use them I recommend you fork this repo instead of cloning it directly, as anything here might change at any time.

Repository Structure

The individual directories of this repository all contain configurations for either a single piece of software, or for a bundle of related applications. They are intended to be modular and to depend upon each other as little as possible.

Note on Terminology

  • link: Links here always stand for symbolic links. The same goes for derived words like linking, etc.

  • module: With modules, the individual configuration directories are meant.

  • linking a module: Linking a module means linking all files of the module directory into the filesystem.

  • unlinking a module: Unlinking a module means removing its links from the filesystem.

  • initialising a module: Initialising a module means preparing it for linking on a specific machine, i.e. creating its state file.

(Un-)Linking Procedure

When linking or unlinking a module, the following happens:

Say we are working with a module_a, whose root we have configured to be /fs/modules/a (via .state.zsh, see Module Structure).

Now, when linking, a file with relative path module_a/files/file will produce a symlink /fs/modules/a/files/file pointing back to it. Any directory on that path which does not exist yet will be created.

When unlinking, on the other hand, if there exists some file module_a/files/file within the module, then any file that is a link (link as defined by the -h unary conditional operator of ZSH) at /fs/modules/a/files/file will be deleted. Any directory on that path which is left empty after the deletion of the link will also be removed.

Duly note, however, that this process will never create links to directories. It traverses modules recursively and only operates upon regular files (regular file being defined by the -f unary conditional operator of ZSH).

Module Structure

Overview

The individual modules, in addition to the regular files that should be linked as described above, contains three additional files, which will not be linked, in its root directory.:

File Optional Version Control Description
.state.zsh no no State File
.state.default.zsh yes yes Default State File
README.txt yes yes Documentation

State File

The file .state.zsh shall set two shell variables:

  • MOD_ROOT: The absolute path of the module root (this should be set manually).
  • MOD_LINKED: 1 if the module is currently linked, anything else otherwise (this should be set manually only for debugging/recovery purposes).

Default State File

The file .state.default.zsh shall be the module-specific default for the .state.zsh file. If it exists, then the initialisation process will copy it to .state.zsh, and if it doesn't, then the .state.zsh will be created according to the global default.

Documentation

The file README.txt shall contain documentation regarding the module. The contents of this file will be displayed after a successful link operation.

About

My collection of dotfiles for all sorts of different configuration purposes

Resources

Stars

0 stars

Watchers

1 watching

Forks

Contributors