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

Dotfile madness (2019)

0x46.net

Post reply on HN
Print view View original

41–50 of 185 posts

Re: Dotfile madness (2019)

#41

Post by deburo »

delta_p_delta_x wrote: post #33

What I personally find more egregious are dotfiles and dot-dirs on Windows , created by half-baked ports of Unix-first software (such as `ssh`). Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths. Windows also doesn't know what the dot at the beginning of a…

On Windows anyway, the root of the user profile is already filled with garbage directories, and so a few more dot-dirs and files feel par for the course. The advantage is that accessing your root dir is easier than typing out %appdata% in File Explorer.

Re: Dotfile madness (2019)

#42

Post by fiddlerwoaroof »

slondr wrote: post #4
bee_rider wrote: post #3

Eh, I dunno. XDG is just some group or whatever, dropping config files in .programname is the de-facto community standard. If people want to follow XDG that's fine, but I can't blame anybody who wants to ignore all that noise.

XDG has real practical benefits, though.

I personally hate the XDG directories. It’s annoying for different part of an application’s data to be split between `~/.config`, `~/.Cache`, etc. Rather than for all the data for the `foo` program to be in a file named something like `~/.foo*`

Re: Dotfile madness (2019)

#43

Post by alwillis »

hyperupcall wrote: post #7

I completely agree! That's why I created this site: https://xdgbasedirectoryspecification.com . We need some place where people can immediately understand the practical benefit, and the minimum ask of their users. Of course, it doesn't help just to complain about the issue in a void, so I've also submitted like 10 PRs and filed quite a few issues. Projects like pnpm and Poetry took note, and now they comply! Someone'…

The following programs are for Linux only (The XDG Base Dir Spec isn't inherently followed for MacOS and Windows)

You should fix this. While macOS and its system applications and bundled applications don't adhere to the XDG Base Directory Specification; many programs that run on macOS do.

In fact, almost all of the programs you list run on macOS and (by definition) use the XDG Base Directory Specification. So I would clean that up to not give an incomplete statement.

BTW, the macOS directory structure [1] has been documented since macOS (MacOS X back in the day) shipped in 2001.

[1]: https://developer.apple.com/library/archive/documentation/Fi...

Re: Dotfile madness (2019)

#44

Post by gaganyaan »

hyperupcall wrote: post #7

I completely agree! That's why I created this site: https://xdgbasedirectoryspecification.com . We need some place where people can immediately understand the practical benefit, and the minimum ask of their users. Of course, it doesn't help just to complain about the issue in a void, so I've also submitted like 10 PRs and filed quite a few issues. Projects like pnpm and Poetry took note, and now they comply! Someone'…

Am I missing something, or should the Python example use "config_dir[0] != '/'"?

I.e. if it's empty, or if the first character is not a forward slash, then use the default?

Re: Dotfile madness (2019)

#45

Post by pabs3 »

This is kind of a thing of the past with Flatpak, since apps can only create files within their sandbox's $HOME, which isn't the same as the user's $HOME. Now we just need deb/rpm/etc apps to be sandboxed in a similar way using bubblewrap (the tool Flatpak uses for sandboxing).

Re: Dotfile madness (2019)

#46

Post by alwillis »

bee_rider wrote: post #3

Eh, I dunno. XDG is just some group or whatever, dropping config files in .programname is the de-facto community standard. If people want to follow XDG that's fine, but I can't blame anybody who wants to ignore all that noise.

If people want to follow XDG that's fine, but I can't blame anybody who wants to ignore all that noise.

Literally every program I’ve installed for the last several months--WezTerm, Neovim, bat, broot and many more just use XDG by default. Most of the time, the user doesn’t have to do anything, though they might initially be confused if they’re looking for their config files.

Re: Dotfile madness (2019)

#47

Post by helf »

pabs3 wrote: post #45

This is kind of a thing of the past with Flatpak, since apps can only create files within their sandbox's $HOME, which isn't the same as the user's $HOME. Now we just need deb/rpm/etc apps to be sandboxed in a similar way using bubblewrap (the tool Flatpak uses for sandboxing).

Yeah… but then you are using flatpaks.

Re: Dotfile madness (2019)

#48

Post by kragen »

hyperupcall wrote: post #9
bee_rider wrote: post #3

Eh, I dunno. XDG is just some group or whatever, dropping config files in .programname is the de-facto community standard. If people want to follow XDG that's fine, but I can't blame anybody who wants to ignore all that noise.

strongly disagree - as of 2022, more apps follow the XDG Base Directory Specification than not - in fact, by a wide margin. So by "doing dirty" in your users home directory, you're going against the grain of the ecosystem. It doesn't seem like you understand much about the specification? I'd recommend reading it, or at least a short summary I've made available here: https://xdgbasedirectoryspecification.com/

My home directory has dotfiles for aspell, bash, bzr, cargo, Clojure, CPAN, CVS, Darcs, D-BUS, Dillo, DOSBox, DOSEmu, Emacs, Eclipse, Emacs, ESD, FLTK, fontconfig, FontForge, GForth, GHC, the GIMP, Git, GnuPG, Gnuplot, Guix, IceWM, Idle, Java, John the Ripper, Jython, Links2, MilkyTracker, Mozilla (Firefox), MPlayer, Nethack, Octave, Racket, R, Skeinforge, Slic3r, SSH, SQLite, Subversion, Units, Vim, W3M, WINE, X-Windows, XScreenSaver, and zsh, which is 51 "apps". Some of those have been there since last millennium, and it would not improve my user experience for those "apps" to look for my configuration file in two different places, or to stop looking in the place they've been looking for decades.

(God forbid I should use remote CVS again, but if I do, I sure don't want to have to debug where the fuck it's sticking .cvspass now.)

There are another 41 things in .config, including Bitcoin, Calibre, Chromium, DjVuLibre, Gomuks, htop, Inkscape, Mumble, OpenSCAD, Transmission, and other things. If I had to choose, I would say that those are the things "going against the grain of the ecosystem". But I think it's fine. As long as it doesn't change in another ten years to be .Config, or .conf, or Configuration, or either Configuration or Configuración depending on whether I installed the machine in English or Spanish. Because then I am seriously going to look into government surplus cruise missiles.

Re: Dotfile madness (2019)

#49

Post by kragen »

fiddlerwoaroof wrote: post #42
slondr wrote: post #4

Earlier quoted context omitted.

XDG has real practical benefits, though.

I personally hate the XDG directories. It’s annoying for different part of an application’s data to be split between `~/.config`, `~/.Cache`, etc. Rather than for all the data for the `foo` program to be in a file named something like `~/.foo*`

I find it useful; I might want to version-control .config but definitely not .cache. And if the program is broken I might blow away .cache but not .config.

Re: Dotfile madness (2019)

#50

Post by scintill76 »

bee_rider wrote: post #3

Eh, I dunno. XDG is just some group or whatever, dropping config files in .programname is the de-facto community standard. If people want to follow XDG that's fine, but I can't blame anybody who wants to ignore all that noise.

> XDG is just some group

vs

> the de-facto community standard

Feels like you’re just selectively defining “community” to exclude XDG. Maybe there’s a good reason, but you haven’t really described it.

Whoever defined $HOME as a place to stick configuration files was also “just some group.”

Post reply on HN