Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use the XDG Base Directory Specification

xdgbasedirectoryspecification.com

Post reply on HN
Print view View original

31–40 of 214 posts

Re: Use the XDG Base Directory Specification

#31

Post by clhodapp »

Eduard wrote: post #12

> ... State :... if the data is unique for a given machine, the file belongs [to $XDG_STATE_HOME / $HOME/.local/state] This statement is misleading/wrong. Like all other XDG stuff, it's not about the machine, it's about the particular user. Also, why does the author consider the given positive example clean and tidy, when it has files .profile and .bashrc placed directly in the user's home directory? Following the ru…

It doesn't feel tidy to have .cache or .config out at the root of home folder either. IMO, those should be pushed down into .local. At least with the xdg base spec you can do that!

Re: Use the XDG Base Directory Specification

#32

Post by 000ooo000 »

In what world is simply dumping config items for your app in the user's home directory sensible? Why stop at config items? Do cache or temp crap too. The thought process of persisting with this baffles me. Microsoft would be absolutely ridiculed if one day your msword preferences appeared on your desktop as an XML file, and no matter what, it kept reappearing.

Re: Use the XDG Base Directory Specification

#33

Post by yjftsjthsd-h »

kitsunesoba wrote: post #7

The 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.

If everything honored this spec, including the part where it reads environment variables to see where the different directories are, you could do that by sticking the right variables in your environment.

I think the one legitimate exception to the rule is profile, because you need that in order to set the variables in the first place. So that one would somehow have to be hard coded to at least have a wider search path

Re: Use the XDG Base Directory Specification

#34

Post by yjftsjthsd-h »

sigmonsays wrote: post #26
fiddlerwoaroof wrote: post #3

I 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

i agree too, All i've seen is a mess of conflicting standards. Is the dotfile now in ~/.local, or ~/.config or what?

It should be in $XDG_DATA_HOME/app/

Re: Use the XDG Base Directory Specification

#35

Post by kitsunesoba »

TacticalCoder wrote: post #30
kitsunesoba wrote: post #7

The 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.

> The second example is a nice start, but I'd really like to see invisible files/folders in ~/ done away with altogether. A great many amazing tools shall, by default, skip searching in hidden files (and gain a great speedup thanks to doing that). You'd have to modify all these tools so that they'd skip Library/ by default. Also, related to that, what would you do with .git/? Move prjs/fizzbuz/.git to Library/fizzbuz…

Things like .git are fine I think, because they’re localized one-offs and have more of a reason to be hidden. It’s the home folder’s function of a junk drawer that makes invisible files/folders a problem there.

Re: Use the XDG Base Directory Specification

#36

Post by clhodapp »

yjftsjthsd-h wrote: post #33
kitsunesoba wrote: post #7

The 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.

If everything honored this spec, including the part where it reads environment variables to see where the different directories are, you could do that by sticking the right variables in your environment. I think the one legitimate exception to the rule is profile, because you need that in order to set the variables in the first place. So that one would somehow have to be hard coded to at least have a wider search pat…

Maybe your profile location ought to be something that you're able to set through chsh

Re: Use the XDG Base Directory Specification

#37

Post by eviks »

fiddlerwoaroof wrote: post #3

I 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 hidden part is another usability mistake, but the main benefit of XDG is respecting user's choice who can set an env var to avoid the mess, hope you wouldn't disagree with an option the improves someone's life without affecting yours in any way?

Re: Use the XDG Base Directory Specification

#38

Post by heywoodlh »

000ooo000 wrote: post #32

In what world is simply dumping config items for your app in the user's home directory sensible? Why stop at config items? Do cache or temp crap too. The thought process of persisting with this baffles me. Microsoft would be absolutely ridiculed if one day your msword preferences appeared on your desktop as an XML file, and no matter what, it kept reappearing.

Yeah, although, I'm not a huge fan of Microsoft's default config file locations either.

Some examples:

- PowerShell Core's default profile is in $HOME\Documents\PowerShell -- or if you have OneDrive enabled, $HOME\OneDrive\Documents\PowerShell.

- Windows Terminal is $HOME\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json.

I can feel pretty confident assuming that if Microsoft can place their power users' config files for Microsoft's Terminal and Microsoft's primary shell in seemingly unrelated locations and not get huge complaints, I would imagine that most Windows users are probably not people who would ridicule Microsoft for placing an XML file in their home directory.

EDIT: I used these examples specifically, because a Terminal Emulator and shell profile are the exact kind of apps you would store configs for in a dotfiles repo.

Post reply on HN