antidot is a similar tool, it automatically moves the files if you tell it to, then it generates a file you can source so you set all the correct variables. I used it to catch things xdg-ninja didn't catch and moved the variables from the generated file to the same place I placed the ones from xdg-ninja.
Good information. One problem I'm having in following the suggestions provided by XDG-Ninja is that I can't always tell if the export of the Environmental Variable is referencing a file or a directory. In some cases, it's obvious, not so much in other cases.
Could u please do a video explaining the standard and what xdg-user-dir-update does? Cause I am from Spain and I cant understand it reading it, but when I see ur videos I can understand, please 🥺❤️. Love u buddy
Matt, Great but I learned that /home is Your personal directory. What happens if one moves files outside /home and another user is doing the same and changes some parameters ? In a single user it's not a problem, but in a multiuser environment ? Is that un problem ? Thanks.
Another timely video. I was just messing with XDG-Ninja last week. I think it has too many dependencies, but that's a minor nit. Like you I learned that quite a few of my daily use tools could be configured to "comply" with the XDG spec. It also encouraged me to read the spec a little more closely, which is my favorite part about discovering a new tool. If it doesn't make me want to learn, it's not as interesting. My environment variables look pretty much the same as yours with a couple differences. I don't use a .zshenv and just left .zshrc in ${HOME}. I thought about configuring ZDOTDIR in /etc/zsh/zshenv and moving .zshrc into ${XDG_CONFIG_HOME}, but I didn't want to create another dependency for my shell environment. I'm also very particular about setting variables. I always test for the presence of the file or directory before declaration, especially command aliases. Defensive programming in a shell environment file seems like overkill until you put that custom environment on a host you didn't build and an alias returns "command not found" because something isn't installed exactly where you specified, or not at all. I could just bite the bullet and update my Ansible playbook, but then I'd have one less thing to complain about, wouldn't I?
@@Reichstaubenminister I left this comment almost a month ago, but I think I was referring to installing glow from a source outside my configured package repositories. I like to minimize use of third party repositories, and I especially don't like using source compiles or pulling binary packages from GitHub repositories unless there is no better option. Like I said, in this case it's a minor inconvenience.
@@Reichstaubenminister As long as xdg-ninja is not in the Debian package repository, there will still be plenty of non-XDG specification software. Reasons: 1. Many major consumer distributions such as Ubuntu and Linux Mint are based on Debian. 2. If it's in the Debian repository, then the hurdle to installing it is much lower. 3. The Debian repository inspires trust. This is something a loose script on Github alone cannot do. 4. If many users can use it because of reasons 1-3, then there will be many more users putting pressure on software developers to implement the XDG specification in their software. Conclusion: So if you want to achieve something, then you should make a request in Debian for the script to be packaged in Debian.
I really hate that its output is full of escape codes and markdown rather than good old plain text. Even worse is he won't fix it. It's trivial to remove the cruft in vim or with sed, but why should I have to?
Everybody thinks this means "Make your wife happy at all costs and your life will be happy." That's not what it means. It means "If she's not a happy woman, don't marry her."
As long as xdg-ninja is not in the Debian package repository, there will still be plenty of non-XDG specification software. Reasons: 1. Many major consumer distributions such as Ubuntu and Linux Mint are based on Debian. 2. If it's in the Debian repository, then the hurdle to installing it is much lower. 3. The Debian repository inspires trust. This is something a loose script on Github alone cannot do. 4. If many users can use it because of reasons 1-3, then there will be many more users putting pressure on software developers to implement the XDG specification in their software. Conclusion: So if you want to achieve something, then you should make a request in Debian for the script to be packaged in Debian.
This is a neat little script that should not have a reason to exist. I'll never understand why "Oh, we added an environment variable that you can set" is considered a solution to this problem. You have a hard-coded path or, if a variable is set, a different path. There already is a variable for that. It's called XDG_CONFIG_HOME - just please respect it. It's the same amount of code, the exact same kinds of logic and the same problems that need to be dealt with. Like conflict resolution if both paths have configuration files or something. Why then does this variable have to be something custom, when there already is a well defined variable? What's the difference? (Not to pick on ansible, but …) What makes "$ANSIBLE_HOME" preferable over "$XDG_CONFIG_HOME/ansible"? What difference does it make? Why do users have to dig through documentation and deal with all the inconsistencies of environment variables, where to set them and in which contexts they do or don't apply … (environment variables are a mess) I totally get it for legacy applications that predate the specification like SSH, but for relatively new applications? For me the worst ones are ones that don't even put a dot in the name. Oops, you installed an AUR package, you didn't know it was written in Go? Too bad, now there's a random ~/go folder. It's super annoying.
You can have them in either .bash_profile or .profile, don't have both profiles or you will have problems. Fish you can export from your .profile don't matter. A lot of people have a misunderstanding about fish, it's not as bad as people make it out to be. Bash can export to fish alias and env variables, not functions I have a hack for that.
When you got to the github page and mentioned "cabal" I was like.......what? Matt is using a Haskell program? :D
Hi DT ( ╹▽╹ )
I do in fact use a Haskell program. Pandoc is wondeful. But I cringe every time it updates. All those blasted dependencies. lol
@@TheLinuxCast all those dependencies mean is that pandoc is inline with the UNIX pholisophy.
@@TheLinuxCast pandoc-bin in the AUR fixes this
This is very nice. Saves me a trip to the arch wiki and searching the page for every item in home.
antidot is a similar tool, it automatically moves the files if you tell it to, then it generates a file you can source so you set all the correct variables. I used it to catch things xdg-ninja didn't catch and moved the variables from the generated file to the same place I placed the ones from xdg-ninja.
my problem is i keep compiling in my $HOME and it look like a mess >_< like DXVK, mangohud, monogams, VKD3D-Proton and so on >_>
I love that this reminds me of rookie mistakes I made with variables.
that ".fehbg" pronunciation made me laugh lol
Yup. Pretty sure I had a stroke or something.
That's true ☺
Good information. One problem I'm having in following the suggestions provided by XDG-Ninja is that I can't always tell if the export of the Environmental Variable is referencing a file or a directory. In some cases, it's obvious, not so much in other cases.
Matt you should put the reference links at the top of the description, not the middle.
Could u please do a video explaining the standard and what xdg-user-dir-update does? Cause I am from Spain and I cant understand it reading it, but when I see ur videos I can understand, please 🥺❤️. Love u buddy
Obviously, one of your talents is organization. Another is finding cool tools.
librewolf advocates freedom, yet it prevents you from moving its file
IRONIC
Matt, Great but I learned that /home is Your personal directory. What happens if one moves files outside /home and another user is doing the same and changes some parameters ? In a single user it's not a problem, but in a multiuser environment ? Is that un problem ? Thanks.
Another timely video. I was just messing with XDG-Ninja last week. I think it has too many dependencies, but that's a minor nit. Like you I learned that quite a few of my daily use tools could be configured to "comply" with the XDG spec. It also encouraged me to read the spec a little more closely, which is my favorite part about discovering a new tool. If it doesn't make me want to learn, it's not as interesting. My environment variables look pretty much the same as yours with a couple differences. I don't use a .zshenv and just left .zshrc in ${HOME}. I thought about configuring ZDOTDIR in /etc/zsh/zshenv and moving .zshrc into ${XDG_CONFIG_HOME}, but I didn't want to create another dependency for my shell environment. I'm also very particular about setting variables. I always test for the presence of the file or directory before declaration, especially command aliases. Defensive programming in a shell environment file seems like overkill until you put that custom environment on a host you didn't build and an alias returns "command not found" because something isn't installed exactly where you specified, or not at all. I could just bite the bullet and update my Ansible playbook, but then I'd have one less thing to complain about, wouldn't I?
Too many dependencies? Which?
@@Reichstaubenminister I left this comment almost a month ago, but I think I was referring to installing glow from a source outside my configured package repositories. I like to minimize use of third party repositories, and I especially don't like using source compiles or pulling binary packages from GitHub repositories unless there is no better option. Like I said, in this case it's a minor inconvenience.
@@gtak-welder That makes sense, but glow is optional.
@@Reichstaubenminister As long as xdg-ninja is not in the Debian package repository, there will still be plenty of non-XDG specification software.
Reasons:
1. Many major consumer distributions such as Ubuntu and Linux Mint are based on Debian.
2. If it's in the Debian repository, then the hurdle to installing it is much lower.
3. The Debian repository inspires trust. This is something a loose script on Github alone cannot do.
4. If many users can use it because of reasons 1-3, then there will be many more users putting pressure on software developers to implement the XDG specification in their software.
Conclusion:
So if you want to achieve something, then you should make a request in Debian for the script to be packaged in Debian.
I really hate that its output is full of escape codes and markdown rather than good old plain text. Even worse is he won't fix it.
It's trivial to remove the cruft in vim or with sed, but why should I have to?
💯 clean home = happy wife = happy life
computer wife ಡ ͜ ʖ ಡ
no wife = happy life
Everybody thinks this means "Make your wife happy at all costs and your life will be happy." That's not what it means. It means "If she's not a happy woman, don't marry her."
As long as xdg-ninja is not in the Debian package repository, there will still be plenty of non-XDG specification software.
Reasons:
1. Many major consumer distributions such as Ubuntu and Linux Mint are based on Debian.
2. If it's in the Debian repository, then the hurdle to installing it is much lower.
3. The Debian repository inspires trust. This is something a loose script on Github alone cannot do.
4. If many users can use it because of reasons 1-3, then there will be many more users putting pressure on software developers to implement the XDG specification in their software.
Conclusion:
So if you want to achieve something, then you should make a request in Debian for the script to be packaged in Debian.
GVM.
This is a neat little script that should not have a reason to exist.
I'll never understand why "Oh, we added an environment variable that you can set" is considered a solution to this problem.
You have a hard-coded path or, if a variable is set, a different path. There already is a variable for that. It's called XDG_CONFIG_HOME - just please respect it.
It's the same amount of code, the exact same kinds of logic and the same problems that need to be dealt with. Like conflict resolution if both paths have configuration files or something.
Why then does this variable have to be something custom, when there already is a well defined variable? What's the difference? (Not to pick on ansible, but …) What makes "$ANSIBLE_HOME" preferable over "$XDG_CONFIG_HOME/ansible"? What difference does it make? Why do users have to dig through documentation and deal with all the inconsistencies of environment variables, where to set them and in which contexts they do or don't apply … (environment variables are a mess)
I totally get it for legacy applications that predate the specification like SSH, but for relatively new applications?
For me the worst ones are ones that don't even put a dot in the name. Oops, you installed an AUR package, you didn't know it was written in Go? Too bad, now there's a random ~/go folder. It's super annoying.
I wonder why you are so much obsessed with having a clean $HOME.
He's a neat freak. You should see him with a feather duster and vacuum!!!!
Autism
You can have them in either .bash_profile or .profile, don't have both profiles or you will have problems. Fish you can export from your .profile don't matter. A lot of people have a misunderstanding about fish, it's not as bad as people make it out to be. Bash can export to fish alias and env variables, not functions I have a hack for that.