Dotfiles repositories are great because they allow us to centrally manage all of our dotfiles in one location rather than spread out all over our system. They also allow us to share our configuration files between systems and make it really quick to set up a new machine. So let's go ahead and create our own dotfiles repo from scratch. Let's jump over into our terminal. You can place your dotfiles anywhere you like. I'm going to place mine in my code directory in a subdirectory I use for my personal repositories. Inside here, I'm going to make a directory called dotfiles and then cd into that directory and then do a quick git init. There are many ways to set up your dotfiles repo. There are even packages you can install to automate a lot of things.

There are many ways to set up your .dotfiles repo. There are even packages you can install to automate a lot of things. One I used to use is called dotbot, and others use tools like Puppet and Ansible to completely configure their system. My colleague Dries Vins has a video on Laracast dedicated to dotfiles on macOS, which I'd highly recommend. These days, I like to use a simple bash script to keep things minimal. So let's go ahead and create that. Use touch, which will create an empty file, and then we can chmod +x to make that file executable, which means we can do ./install to run our install script. Let's open this up in vim, and the first thing we want to do is add a hashbang. So let's come into insert mode, and we'll say hashbang #!/usr/bin/env bash.

Let's open this up in vim, and the first thing we want to do is add a hashbang. So let's come into insert mode, and we'll say hashbang user vim env bash. And this just tells the shell how to interpret the script. So in this case, we're going to be writing bash script. We're going to be creating symlinks, which are files that just point to another location on the system. Symlinks are created using the ln command, which looks something like this. ln -s for symlink, and then the target, and then the link name. Symlinks can use relative or absolute paths, but if we use relative paths, then they need to be relative to the location where we place the symlink, not relative to where we're running our install script.

then they need to be relative to the location where we place the symlink, not relative to where we're running our install script. So I find it easier to use absolute paths. To use absolute paths, we need the location of our .files repo in our install script. We could hard code it, but I prefer to determine it automatically. It's a little bit complicated to get this, and there are a few ways of doing it, but this is what works for me. So let's u to undo that, and let's press o to append a new line, and let's come down. So I'm going to start by echoing out these things so we can see what we're doing, and then later on we'll convert it into a variable.

So I'm going to start by echoing out these things so we can see what we're doing, and then later on we'll convert it into a variable. So let's start by saying echo bash source 0, and then close that one off. This will echo out the first parameter we pass to our script, which in this case is actually the name of the script. So let's save and quit this with :`wq` and then run our install script. Here we can see it's echoing out the path of our install script, and it's relative to where we're running it. So if we come back a directory and we say ./files/install, then again you can see that that directory is relative to where we're running this command.

So if we come back a directory and we say .files install, then again you can see that that directory is relative to where we're running this command. Let's come back into our .files repo. So we actually want the path to the .files repo, not the path to the install script. So let's come back into our install script, and we want the directory name. So we can say dirname, and then pop that one on the end there. Let's also wrap this in quotes just in case there's ever any spaces in there. And let's run this now and see what we get. So now we can see it's just returning a dot, which just means the current directory. And that's the directory where our install script is found,

So now we can see it's just returning a ., which just means the current directory. And that's the directory where our install script is found, which is also the directory of our .files repo. If we come back again and do .files install, once again you can see it's the relative path from where we are to where our .files are located. Let's come back into our .files repo, and now we want to convert this into an absolute path. So the way that I do this is we want to cd into this directory, and then afterwards we want to go && pwd, which is print working directory or present working directory. And if we run this now, we can see we get the full path to our .files repository. And it doesn't matter if we come back and run that from somewhere else, we still get that full path.

And if we run this now, we can see we get the full path to our .files repository. And it doesn't matter if we come back and run that from somewhere else, we still get that full path. Let's come back into here and back into our install script. So now we are ready to start creating some symlinks. So let's go ahead and convert this into a variable. So let's use caw to change around that word, and then say .files equals. So now we have our variable. I'm going to start by demonstrating how I configure my terminal, because the terminal controls a lot of things about the NeoVim experience. I use a terminal called kitty because it's fast and has the features I like,

because the terminal controls a lot of things about the NeoVim experience. I use a terminal called kitty because it's fast and has the features I like, but you're free to use any terminal you like. Some programs use a single config file, and others have a config directory. In the case of kitty, it looks for a subdirectory in the home directory. So let's go ahead and create a link to that. So we'll say ln -s. We're going to be linking from .files/kitty. So this is going to be a kitty directory in our .files repo, and we're going to place this symlink in $HOME/.config/kitty.

So this is going to be a kitty directory in our .files repo, and we're going to place this symlink in $HOME slash .config slash kitty. Now, some programs, when you first open them, they'll go ahead and create a default configuration file. In this case, we don't want that there, and that will prevent our symlink from working. So we're also going to, before we do this, just go ahead and remove that directory if it already exists so that it's nice and free and clear for adding our symlink. All right, so let's save and quit this, and now we're in our .files directory. Let's just make a directory called kitty,

All right, so let's save and quit this, and now we're in our .files directory. Let's just make a directory called kitty, because that's where we were going to create our symlink from. And let's create a file in there called kitty.conf. That's the name of the config file kitty will look for in that directory. And in here, let's just put a comment in here. For now, we'll say, hello world, and we'll save and quit that. All right, so let's run our install script. It doesn't output anything because we haven't told it to echo anything, so not outputting something is generally a good sign with a Unix command.

It doesn't output anything because we haven't told it to echo anything, so not outputting something is generally a good sign with a Unix command. All right, so let's go into that directory where we're expecting our symlink. So it's .config, and let's list and filter to kitty. And here we can see our kitty file in this directory, and it's a symlink pointing to the kitty directory in our .files directory. If we cd into here, and you'll see that we're still in .config kitty in the home directory. If we do an ls, we'll see our kitty.conf file in here, and if we open that up, we can see the contents.

If we do an ls, we'll see our kitty.conf file in here, and if we open that up, we can see the contents. If we change this to, say, hello laracasts and save this, if we come back now to where we placed our .files repo, so that was in jessarcher.files, and then if we open that kitty.conf, you'll see the change we made in that config directory is reflected here, and that's because this file here is kind of like the source of truth. In the config file directory, we were just kind of linking to this directory from somewhere else.

In the config file directory, we were just kind of linking to this directory from somewhere else. The great thing about this install script is we can run this multiple times, so we can say ./install, and it'll do the exact same thing. It'll clear out that file or directory or symlink or whatever was there and then recreate the symlink. And this is what we call idempotent. It has the same effect the second time we run it as the first time we run it. And this means that when we start adding more things to our install script and we rerun it, it's going to be fine.