 One of the things that Linux users often do is they borrow other people's config files, especially as you grow as a Linux user, as you become more of a intermediate Linux user. You'll go and grab somebody else's dot files. They're config files. They're config files for their window managers or for Vim or for Emacs or whatever it happens to be. Most programs have configuration files that can be saved, and many Linux users do save these config files, which we typically will just call dot files. They're called dot files because most of these config files are hidden files, meaning they start with a period or a dot at the beginning of their names. Now one of the problems with you just going and borrowing somebody else's config file, there's several pitfalls involved, but most of the time when you go and grab somebody else's config file and just put it on your machine, it doesn't work. There will be errors. There will be some hoops you have to jump through sometimes. And today I wanted to discuss some of those pitfalls involved when going and grabbing someone else's dot files. And the reason I'm making today's video is because in here in the last week, especially, I have gotten many comments on my GitLab and also on YouTube of people trying out various config files of mine, and they're running into issues. I don't know. I'm going to mention at least one config file today specifically that I know are causing people issues. And I have some ideas on why it's causing certain people issues. And you know, instead of trying to answer everybody individually, I just wanted to put it on video. I also just thought it made a good topic. But one comment I got on a YouTube video the other day, I think sums up this problem rather well. He writes in, I love these videos, but every time I go to hack on them, I feel like there's a lack of information to get started. So he's talking about, you know, when you're hacking on a window manager, I think is as the video he was watching. I think it might have been one of my X-mode ad videos and there's a lack of information to get started. Well, I disagree. The information out there is just not user-friendly or new user-friendly because, you know, some of these topics get kind of deep. That's why you go and borrow other people's configs, right? Is because, you know, you don't want to have to dig through all the documentation. You hope that you just borrow somebody else's config and it magically works. But most of the time it doesn't. He goes on to write, I like how organized your configs are. I try to organize my stuff and comment heavily. So I appreciate that you find that useful. And he says, you know, I change your config and I spend two hours trying to write my own config. There's no error messages, but then I get an error message and then I have to spend hours trying to fix the problem, yada, yada, yada. And yeah. So this is one of the first pitfalls that you run into when going and getting somebody else's config is the fact that you didn't write the config yourself, right? You're just taking the code that I wrote. So you don't really know what's going on in the code. And that's always going to be an issue anytime you borrow somebody else's code unless you happen to understand the language that it's written in yourself. But if you understood the language it was written in, you probably would have just written your own script to begin with. So most of the time when you go and borrow somebody else's dot files, you probably have no idea what the code is doing. And this is one of the things as you grow, as you start editing that config file and working on it yourself, you will figure out exactly what the script does eventually. But getting started, yeah, you're kind of lost at first. Now I mentioned that I've had several comments here in the last week about a specific dot file of mine. Let me switch over to my desktop. So if I go to my GitLab over at gitlab.com slash dwt1, I've got several repositories here. If I go to view all repositories, I have my dot files repository, which is a very popular repository. A lot of people use my dot files. And one of the most common dot files people grab are my xmonad configs and my xmobar configs. And this xmobar config here, xmobar rc, I have had a lot of people say they go and grab this file and they install it or just place it on their system in dot config slash xmobar on whatever distro they happen to be using. And this doesn't work. And there are several reasons why this is probably not working for you. And when I say there's several reasons, this is probably not working for you. This could be any config file, any dot file that you're going and borrowing from anyone. I'm just using this specific file as an example. But the first thing you have to consider when going and grabbing anyone else's configs is it's the config file up to date, right? How old is this? Was this placed on their GitHub or GitLab, you know, a year ago, two years ago, five years ago, 10 years ago, right? The older the config file, I mean, the older, since the last time it's been updated, the chances are that the program has been updated. That config file, the syntax has changed and, you know, you can't use it with newer versions of that particular piece of software. Now, in this particular case, I keep my configs relatively up to date. This xmobar rc should work as far as the syntax or there should be no syntax that is broken. It is something you do need to consider if I do a back arrow here. You will actually see, like on GitHub and GitLab, they'll actually tell you the last time these files were modified and pushed. So this xmobar rc was last updated two months ago, so not very old. But if you start seeing things that are many months old and certainly several years old, chances are, you know, you're going to have to figure out some of the new syntax if it has changed for that particular program. The next reason this config file may not work for you, even though it's working for the author, and you've got to consider these dot files, the people that are saving them to GitHub and GitLab, these are their config files, right? It's working for them. It's working on their machines. I use all of my configs, right? So I know these configs work on my machine, and that's part of the problem is the next big thing you have to consider is, are you using the same Linux distribution that the author of that config file is using? If you're not, that could be a major issue, because the version of xmobar I'm using on an ArchBase system, because I'm on an ArchBase system, right? It's going to be a different version of xmobar than what you're using on a Debian-based system, for example. You could be several versions behind on Debian than what Arch is on, and that could be a serious issue. And I actually think, in my specific case for my xmobar config here, that is actually the issue most people are having, is they are not using the same versions of software that I'm using. They're not on the same Linux distribution I'm using, an ArchBase Linux distribution. And specifically, what's causing people problems is that they mentioned that the xmobar panel, you can see this is xmobar at the top of my desktop here, these glyphs, these little Unicode characters are not rendering, so the fonts are not rendering. In my xmobar RC, this is the font section. And specifically, the glyphs are font awesome six, right? Here's the thing, font awesome six hasn't been around that long. On Arch, you can install it, I even made a note. By the way, read the comments of config files, because if the author of that config file did a good job, they actually gave you all the relevant information. For example, I included this dependencies line, I tell you, otf-font-awesome, that's the name of the package on Arch, unfortunately, right? So I don't know what it is on Debian or Fedor or anything like that. And also, I don't know if their packaged version of the font awesome package is on version six. It may be a older version. It may be font awesome five, which means you would have to change this on your system, right? This work, this config file works on my machine. I don't know if it's going to work on your machine. So some of this, you'll open issues on these people's GitLab or GitHub, and hey, man, your config file doesn't work. No, I promise you, please don't go and tell these people their config files don't work, especially if it's up to date, because they're probably using their config files, and it probably is working. It's just not working for you. So you just have to be aware that maybe you have to do some research on your own for your distribution, for your machine, and make sure that, you know, if you have to make some minor changes, you're gonna have to do that research on your own. Don't ask somebody who authored that config file to help you out, because honestly, they can't. They're not using your machine. They're not using your Linux distribution. They're not installing the same packages and things like that. They can't help you. They've already done a tremendous amount of work by giving you this config file, right? All right, I put so much time and effort into these things, these config files, right? I've done a lot of heavy lifting here. The fact that, you know, you're having a problem with this font section, right? I'm gonna have to let you guys work out that single paragraph on your own. I can't help you myself. Another major mistake people make when going and grabbing somebody else's config file, I'm gonna go into .xmonad. We're gonna grab my xmonad config here, at xmonad.hs. Be very careful when going and grabbing a specific config file, right? Because a lot of people, well, I'll just copy and paste, right? I'm just gonna select it with my browser and this is a very, very, very long config file. I'm not actually gonna copy and paste it. But anyway, you select the whole file, right? And then you right click and you copy and then you go into your plain text editor and you do a paste. And here's the problem with a copy and paste from the web browser to your text editor. Certain programming languages and Haskell is certainly one of these. Python is another one that, you know, spacing is important in certain programming languages, right? This has to be indented, right here. You know, this block, this do block. You know, there's a reason why these next few lines are indented. They have to be, right? If you do a copy and paste, sometimes it doesn't respect the spacing and the tabbing that was in the original document. And it will completely and totally break the config, right? Even though the config probably does work on your system, you know, if you did that copy and paste and it's a bad copy and paste where it messes up all the indentation, it's going to break on your system. You know, in this case, the Xmonad config here, the Haskell compiler will just spit out a whole bunch of garbage saying the whole thing's broken. It wasn't broken if you would have done the copy and paste the right way. And the right way is to not do a copy and paste. What you wanna do to make sure you get the original file as intended is to actually clone the repository and so go to the very top level of the repository and you have clone here and then you have clone with HTTPS. Grab that link. So just do a copy of that link right there and then open a terminal. Let me open it and we'll make this big and I'll CD into downloads. And then what you wanna do to clone a get repository is get clone and then the URL to that repository, right? And then it's going to clone the entire dot files repository of mine and then go grab the config file or two that you want and then, you know, after you have them then you can delete the rest that you didn't need but that will ensure that you actually get that document exactly as I wrote it with the proper indentation. Now say you go and grab somebody's config file and you put it on your system and it does work which much of the time that will be the case. You'll grab somebody else's working config file that, you know, it works on their system and it'll probably work on your system too. And then you decide, well, I wanna tweak some things. I wanna change some things. And as you're changing things, you break the config. How do you avoid that kind of pitfall? Well, let me switch over to my desktop and I'm gonna just as an example, let's open my Xmonad config. Let me zoom in a little bit here. So say you borrowed this config from me and you know, you wanna change some things. For example, you know, my terminal is a Lackardy. Maybe you wanna use a different terminal. Maybe you wanna use URXBT, right? And then you save it and then you recompile Xmonad, restart Xmonad. That's probably okay. That's a really simple change, right? But the problem is when people start making massive changes to things or, you know, maybe you wanna change a lot. I wanna change the font. I wanna change the mod key. I wanna change these variables for terminal browser, I don't use Emacs, I use Vim. So I'm gonna change that string as well. And then I'm gonna change everything in the startup hook, all of this stuff. And then I've got some workspace information down here somewhere toward the end. Maybe I wanna change all the names of the workspaces. And then I've got rules for various windows, whether they're floating or tiling, yada, yada, yada. And I'm just gonna make all of these changes, keybinding changes. I'm gonna make a million changes to this config file. And then I go and recompile Xmonad and it doesn't recompile correctly. I get a bajillion errors. And you made this massive change to this massive document, right? What's the error? What mistake did you make? You have no idea because you changed so much stuff before trying to recompile. You have no idea what caused the error. So when you're changing these things, change one thing, make small changes, then recompile, then restart, in this case, the window manager or whatever program you happen to be working in, make small changes and then see if it works. If it works, then make the next small change. Don't make a massive change because if things don't work, it's very, very, very difficult at that point to figure out where the error is. And many times you're wasting time doing that because now you spent 30 minutes making this massive change that didn't work and eventually what you're gonna have to do is go back and do exactly what I told you, which is to undo everything you did and then go add things, one chunk at a time, one small little chunk at a time and then you will eventually figure out, okay, this is where I made the mistake. One thing you have to be careful of at any time you're editing these config files or just programming and scripting in general. I mentioned doing the small chunks and then sometimes you'll make a mistake. You need to be able to undo what you just did so it would be nice if the text editor or the IDE that you're working in has the ability to undo a lot of changes or maybe even go back to the last saved state of the file. So you may wanna think about the text editor you're working in, for example, here in Emacs because I'm using the Emacs server, the Emacs daemon, which typically I never kill it. I can probably undo a lot of stuff I've done on this config file for the last several days depending on when the last time I restarted my computer was because restarting the computer, of course, will kill the Emacs daemon. But I can undo a lot of stuff on these various files I work on just because Emacs is always running on my system, right, and it remembers the history. Even if it didn't, Emacs has saved states of files that I can roll back to and that's really important. So that's another thing if you, once you start getting heavy into playing with config files, dot files, especially once you get into scripting, you may wanna consider the text editor that you're using. So these are just a few of the errors that you can encounter when going and grabbing other people's config files, other people's dot files. I just wanted to make you guys aware that maybe you didn't know, because I see too many people going on GitHub, GitLab and telling people, hey man, your config files don't work, your dot files don't work. And be careful how you approach that. It would be better if you asked that person, hey man, does this config file work? I tried it and didn't work for me. Is it working for you? Ask them that first, because 99% of the time their config file is working for them. That's why they're saving it, it's because it works. And then you'll realize it's probably one of these other issues that's the problem for you. Now before I go, I wanna thank a few special people. I wanna thank the producers of the show, Devon Gabe James Maxim, Matt Michael Mitchell, Paul Scott West, Alan Armoredragon, Chuck Mandarin, Greta Iokai, Dylan George, Lee, Lennox Ninja Mike, Erion, Alexander Peace, Archon of the Door, Polytech Realiteats for Luts, Red Prophet, Stephen and Willie, these guys, they're my highest tiered patrons over on Patreon. Without these guys, this episode would not have been possible. The show's also brought to you by each and every one of these ladies and gentlemen. All these names you're seeing on the screen right now. These are all my supporters over on Patreon because I don't have any corporate sponsors. I'm sponsored by you guys, the community. If you like my work and wanna help me out, look for DistroTube over on Patreon. All right guys, peace. And add comments to your dot files if you plan to share them.