Live data from Hacker News

Dotfile madness (2019)

0x46.net

151–160 of 185 posts

Re: Dotfile madness (2019)

#151

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 or whatever

So are ISO, W3C, IETF, etc.

> dropping config files in .programname is the de-facto community standard

Dropping litter and open-air defecation are de-facto community standards in some unfortunate parts of the world. That's not an argument to keep doing it.

Re: Dotfile madness (2019)

#152
post #24

Earlier quoted context omitted.

The idea for your site is great. A quick suggestion: if you want everyone to immediately understand and sympathize with your cause, then use the tools that everyone knows in your examples. Using some long exa incantation risks alienating people that don't care about things like the latest trendy grep alternative. Just use: `ls -d .*` or `ls -a`

Using some long exa incantation risks alienating people that don't care about things like the latest trendy grep alternative Exa is the latest, trendy ls alternative. I don’t think you should remove the Exa example but you certainly should show how to use ls to do something similar for those people still living in the dark ages—ls was created in the 1970s and it hasn’t kept up with the times all that well [1]. I crea…

I appreciate that you are trying to be helpful, but you might be over-evangelizing trendy things at the risk of appearing patronizing; exa is a thing like the latest trendy grep alternative, and the point of my original comment still stands.

No need to have a rosetta stone of alternatives to demonstrate an illustrative example where the basic tool that everybody already knows and understands at a glance works.

I'm not saying that exa, or fish, or ripgrep, or any other trendy tool is bad.

Re: Dotfile madness (2019)

#154
> a Desktop directory. That last one has been created by Steam, which is quite unfortunate as I simply do not have a desktop or a desktop environment on my machine.

Chrome and a number of other software insists on creating some of these directories (e.g. Downloads) too.

However you can fix that by setting XDG_DESKTOP_DIR and XDG_DOWNLOAD_DIR in ${XDG_CONFIG_HOME}/user-dirs.dir to something else (e.g. your home directory).

Re: Dotfile madness (2019)

#155
post #134
post #114

Earlier quoted context omitted.

Also, idempotency of a tool is a desired property that tool devs often invest a lot of effort in maintaining. Initializing default config on the first run is a trivial way to break it. It's much better to just have a sane implicit default value for each setting when config is not present. Then you can list the default config in your docs or offer a CLI flag --print-default-config or --copy-default-config.

Creating a file if it doesn't already exist is idempotent.

Only if you always create the file with the same contents, which is almost certainly not going to be true when the software evolves and adds new options.

Re: Dotfile madness (2019)

#156
You are not gonna like the solution to that problem: Windows Registry like configuration file.

Centralization solve the problem in this case but have the downside that the central configuration file will become bloated and requires more memory in the long run.

Re: Dotfile madness (2019)

#157
post #136

Earlier quoted context omitted.

That still works if it’s `~/.foo/cache`

rm -r ~/.foo/cache ~/bar/cache ~/baz/data/app/cache [20 more apps..] is less ergonomic than rm -r ~/.cache/\*

I think HN escaped the * in that final line before I edited it into a code block and my edit window is expired so I can't fix it

Re: Dotfile madness (2019)

#159

Earlier quoted context omitted.

You're directly depending on platform-specific stuff the moment you look up the user directory, because it's not $HOME on Windows either. There is a difference between being cross-platform, and being Linux but mangling it so it technically works on other platforms.

It's just a different variable: USERPROFILE. https://stackoverflow.com/a/42700844/512904 > being Linux but mangling it so it technically works on other platforms Sounds like the easiest way to solve this problem. I don't blame or shame developers for choosing it. This is simple and works everywhere: char * home = getenv("USERPROFILE"); if (home) { // Use home directory } The answer demonstrating the Windows API way h…

The former does not in fact work everywhere, it only works on Windows. Once you have your #ifdef, there is absolutely no point in having the wrong Windows-specific code instead of the right Windows-specific code. Also, look at what you're describing as weird bullshit: a function call with an enum, instead of a function call with a string. The only difference is that you haven't bothered to familiarize yourself with the world outside of Linux, so it feels unfamiliar.

Also, you're comparing something it makes zero sense to compare. People are not saying 'you need to fetch $USERPROFILE without calling getenv'. People are saying 'you need to not store random garbage in $USERPROFILE'. Calling getenv("APPDATA") is a perfectly fine way of fetching FOLDERID_RoamingAppData, the same way you weren't going to bother calling getpwuid if $HOME was undefined.

Re: Dotfile madness (2019)

#160
post #136

Earlier quoted context omitted.

rm -r ~/.foo/cache ~/bar/cache ~/baz/data/app/cache [20 more apps..] is less ergonomic than rm -r ~/.cache/\*

There’s always: rm -rf ~/.*/cache

Assumes the app uses cache as it's cache, rather than names like dlcontent, bananas_content, storage.sqlite, assets, meta, $TIMESTAMP.txt etc.
Post reply on HN