Hacker News new | ask | show | jobs
by kitsunesoba 1178 days ago
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.

5 comments

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

Maybe your profile location ought to be something that you're able to set through chsh
Huh. So I was about to disagree because that felt like a kludge, but actually you're right; setting your shell and its environment are both things that have to be set before the user's normal environment is working for bootstrapping reasons, so yeah, it does make perfect sense to cover both with the same mechanism. Or maybe to make it more generic we could replace the "shell" line in passwd with a "login command" entry, which is always executed by the system /bin/sh with the system environment from /etc/profile? Then you could set it to `XDG_CONFIG_HOME=$HOME/mydotfiles /bin/shell`, or `/bin/decrypt-my-home; export XDG_CONFIG_HOME=$HOME/Library/config; exec /bin/bash --init-file $HOME/Library/bash/bashrc` or whatever you want.
There is a system-wide /etc/profile or /etc/profile.d/

Likewise, zsh will look for /etc/zshrc

And zsh will actually look at

    $ZDOTDIR/.zshenv
    $ZDOTDIR/.zprofile
    $ZDOTDIR/.zshrc
    $ZDOTDIR/.zlogin
    $ZDOTDIR/.zlogout
So perhaps you can set the value of ZDOTDIR in one of the systemwide locations to use "$HOME/foo/bar/zsh/" and this way zsh will use ~/foo/bar/zsh/ as the location for the user specific .zshrc and other mentioned files for every user

https://eng.libretexts.org/Bookshelves/Computer_Science/Oper...

https://bash.cyberciti.biz/guide/Setting_system_wide_shell_o...

https://zsh.sourceforge.io/Intro/intro_3.html

Yep! On my real systems, my configured shell is a wrapper which sets ZDOTDIR and execs zsh from my nix profile.
Honestly, when your xdg list gets huge, apps should just use xdg out of the box... my /etc/profile is 35 lines of just xdg junk.
What the heck are you talking about? The XDG basedir spec is three variables. The user dir spec is more but those are not environement variables.
So that's not any fault of XDG, that's you forcing applications to use it when they apparently don't support it natively. That's either 15 or 19 lines of application bugs.
Reread what I said, "apps should just use xdg out of the box"
You could set the variables in a pam module, then you don’t need to worry about profile
Luckily if you’re a developer on MacOS, you can have that too! In addition to ~/.config and a million .dotfiles and .dotdirectories from decades of unixy tools! Truly a cornucopia.
It's frustrating enough to make a person seriously consider maintaining forks of all the FOSS things they use to fix this one bit of misbehavior.
Start with pythons “projectdirs”, which refuses to allow mac systems to use XDG or at least have that option.

https://github.com/platformdirs/platformdirs/issues/4

Do any of the Linux distros do this? Strikes me as the kind of thing Debian would do for everything in apt
Do you have any examples of Debian doing this?
Sure. In software of mine distributed by Debian, there's usually a "debian/patches" directory, that I didn't add, that's changes the Debian project wanted to make to the system. I'm sure there's a formal name for that system. Most Debian packages seem to have one.
In Windows we get dotfiles from any tool badly ported from unixland, plus the myriad ways specified by various Windows standards over the past several decades, plus the innumerable ways that different entities have chosen to interpret those standards, plus whatever bullshit non-standard locations some asshole thought up and decided to ship.

Where is the config for program X?

It could be in the same directory as X, HKLM\Software\X, HKCU\Software\X, The HKLM\Software\XWOW6432Node\X, AppData\Local\X, AppData\Remote\X, AppData\LocalLow\X, ProgramData\X, USERPROFILE\.X, USERPROFILE\Documents\X, USERPROFILE\Saved Games\X, USERPROFILE\Documents\My Saved Games\X, USERPROFILE\.config\X...

Yep. Makes backing up configurations on Windows systems somewhat nightmarish… it's most practical to just back up the whole install and then pray that you'll never have to go digging for any specific bit of config in particular.
What does Library actually mean though? ;)
Library is such a ridiculous name. It used to be called the Preferences Folder AKA etc AKA .config AKA .local AKA ~/\.*

This is the problem with preferences: everyone's preferences are different!

Apple macOS. Don't ask…
> 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/fizzbuzz/git while keeping prjs/fizzbuzz?

This is, hopefully, never going to happen.

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.
I already do this. .git/ is a visible folder name-of-project/ in another location:

  $(infernalpath loc)/version-control/git/path-to-project/name-of-project
  $(infernalpath loc)/version-control/fossil/path-to-project/name-of-project
Yeah, it's a bit alien on macOS. There is no good mapping for some of these folders.

For example, on macOS application configuration isn't even supposed to be done directly via application-specific files. macOS has its User Defaults subsystem, with `defaults read`/`defaults write` commands. And of course this isn't usable by typical command-line tools that don't have a Bundle ID.

The system that you mentioned is specifically for macOS Desktop apps. I think even Apple is drawing a line there. I don‘t know of any Apple commandline tool which has a configuration in plist format etc. But I might be wrong.
Apple ships some BSD and Linux tools (openssh, git) without changing how they store configuration, but anything written with macOS in mind has other methods. For example, Apple's command-line build tools for Xcode inherit GUI Xcode's settings and project files that are plists. launchctl uses XML plists in ~/Library instead of /etc. Daemons like Spotlight and Time Machine are configured via plist-editing GUIs or mdutil/tmutil commands.