or•i•gin (ôrˈə-jĭn, ŏrˈ-)
n. The point at which something comes into existence or from which it derives or is derived.
n. Ancestry: “We cannot escape our origins, however hard we try” (James Baldwin).
n. The fact of originating; rise or derivation: The rumor had its origin in an impulsive remark.
– The American Heritage® Dictionary of the English Language, 4th Edition
This little project will create a new $HOME
directory tree for a clean computer system or a fresh user. The tree structure follows the home-directory specification on my blog with slight tweaks and adjustments based upon the host operating system.
It’s intended to be used in the same spirit as my dotfiles: after a machine is built or a fresh user created, clone this repo’ and then cast the spell to build a familiar home base.
Indeed one would probably clone several repo’s and then run them:
- dotfiles first, to have some familiar feel to the shell and other utilities
- my tool-chain installer, then use it to install tools required on the new machine
- this origin repo, for setting up the look of my
$HOME
- spacemacs to install the spacemacs emacs editor configuration base
- dotspacemacs to configure spacemacs to my personal preference
Early after creating a new $HOME
(or %USERPROFILE%
) directory on the host machine, follow these steps to build it out:
- Clone this repo (requires that
git
be installed)
$ git clone git@github.com:sinewalker/origin.git ~/Projects/origin
- Build the new
$HOME
:
$ ~/Projects/origin/go #Unix
or
C:\Users\lockha> Projects\origin\go #Windows (Powershell)
By using this command, the host operating will automatically launch the correct script to build this directory structure (Unix will run ~/Projects/origin/go
, whereas Windows will pick up ~\Projects\origin\go.ps1
)
This is specifed on my blog. The fine/current details are contained in the nodes.json
configuration for this project. I have deliberately separated the structure out from the mechanics of building appropriate directories and links so that if the repo’ is forked, it can easily be customized to your own needs.
In the configuration file (which is JSON), each node in the directory tree is specified like this:
{
"node": {
"name": "foo",
"disposition": {
"linux": {"link": "~/Foo"},
"macos": "dir",
"doors": null
},
"children": {
"node": {
"name": "bar",
"disposition": {
"linux": "dir",
"macos": "dir",
"doors": "dir"
},
"children": null
}
}
}
}
Rather than list the same nodes multiple times for each operating system, each has a list of disposition
values for each target OS we’re building on. The OS will be detected by the script and then the each node created according to the disposition
for that OS.
Node dispositions are grouped by operating systems. The different OSes are:
linux
: any flavour of Linuxmacos
: an Apple Macintoshdoors
: Microsoft Windows (that’s a Piers Anthony reference, and it makes 5 letters)
The different disposition
values are:
dir
: make a directory for this nodelink
: make a link to the node named in the valuebuiltin
: this node should exist already, do nothingnull
: do nothing (node not required on this OS)
If the node needs sub-directories/nodes, these are listed in children
, if not then children
is null
. The child nodes are specified in the same way, and may also have children.
It should be possible to fork this repo’ and then change the nodes.json
to meet your own requirements. That would require no changes to the code, but possible extensions that would require hacking the code might be:
- new operating systems (maybe you have different node requirements for AmigaOS, or Solaris, which aren’t implemented)
- more dispositions (e.g. maybe bind-mounts, or Windows Joins?)
- different implementation languages (maybe python or powershell aren’t available on your platform)