Use the XDG Base Directory Specification
xdgbasedirectoryspecification.com
Use the XDG Base Directory Specification
1–10 of 214 posts
Re: Use the XDG Base Directory Specification
#2Yes!
Some projects are stuck for years trying to implement this. Firefox for example.
> .audacity-data
Recent Audacity already fixed this.
Re: Use the XDG Base Directory Specification
#3I strongly disagree: the dot files cause very little inconvenience because they’re typically hidden and they’re easier to type and list than the XDG spec stuff
Re: Use the XDG Base Directory Specification
#4I strongly disagree: the dot files cause very little inconvenience because they’re typically hidden and they’re easier to type and list than the XDG spec stuff
The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better?
You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.
Re: Use the XDG Base Directory Specification
#5I strongly disagree: the dot files cause very little inconvenience because they’re typically hidden and they’re easier to type and list than the XDG spec stuff
vi .co[tab]app[tab] is much easier to remember and type when everything is in the right place.
Re: Use the XDG Base Directory Specification
#6I strongly disagree: the dot files cause very little inconvenience because they’re typically hidden and they’re easier to type and list than the XDG spec stuff
The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.
> The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better?
Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI.
> You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.
Either of the first two is easier to work with than the XDG-compliant way, and the last is no harder.
Re: Use the XDG Base Directory Specification
#7The second example is a nice start, but I'd really like to see invisible files/folders in ~/ done away with altogether.
So starting with that example, I might add a visible ~/Library/ folder, then move ~/.config/ and ~/.local/ in there as ~/Library/Config/ and ~/Library/Local/ as normal visible folders. Same for .bashrc, .profile, etc; put them in ~/Library/Config/ without the dots.
Re: Use the XDG Base Directory Specification
#8I strongly disagree: the dot files cause very little inconvenience because they’re typically hidden and they’re easier to type and list than the XDG spec stuff
Isn't it great that it's optional? I love how Linux is like that. We can all be happy
Re: Use the XDG Base Directory Specification
#9Earlier quoted context omitted.
The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.
> The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI. > You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.confi…
FYI, and nothing personal, but your comment is more or less coming across to me as "whelp, the inflexible delegation has spoken".
I go to great lengths to maintain a flexible mindset, to try to get the best out of a new approach. Hearing/reading someone trying to throw a shallow take-down of something they haven't tried doesn't read as "ooh that person is so cool I'm super convinced"... it comes across more like "oh, poor fella went and got his brain rigidized... and at such a young age".
But maybe you'll come around. Maybe people will come around and realize the ankle-deep hot takes are worse than useless and we can all get back to the good stuff.
On the other hand, I do have my own suspicions. At first glance it does simply sound like another layer of idiosyncrasy to jam into the memory hole, something that will certainly never be universally adopted and just add more hidey-holes to search for config files.
But, as I hope I made clear, I'm willing to give it a shot because I don't trust myself to have absolute insight into a thing after a couple minutes reading. There may well be aspects to this that I can't conjure, but will really like after all is said and done.
Re: Use the XDG Base Directory Specification
#10Earlier quoted context omitted.
The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.
> The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better? Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI. > You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.confi…
[dead]