Live data from Hacker News

Dotfile madness

0x46.net

61–70 of 534 posts

Re: Dotfile madness

#63
post #3

Why do programmers do this? What thought process leads to someone thinking this is a good idea?

In order to have per user settings you have to have one dir per user. For practical purposes and security it ought to be somewhere only user has access it. Optionally it would be nice if you could back up all user settings and files in one place.

The logical conclusion is that it ought to live somewhere in home which meets the above criteria. Its obviously cleaner to store data in $XDG_* but keep in mind that some of the apps creating said files are actually older than linux and certainly older than such standards.

From dev and user perspective it would be nice to have them updated to follow the standard but in practice the practical effect is nil so lots of stuff doesn't bother.

Re: Dotfile madness

#64
post #38

From a user standpoint, a lot of of unrecognizable things show up if you pass that -l flag. In my opinion, having a conventional place to look for user configuration in plain text is a good thing, not a bad thing, and of course I would want it to be in the directory on my system where I'm the sole owner. As somebody else mentioned, this means backing up my personal settings and files is braindead simple, too. Asking…

> Having a conventional place to look for user configuration in plain text

That place is $XDG_HOME_CONFIG (~/.config)

Re: Dotfile madness

#65
The lack of useful names on the files is IMHO the most egregious issue. (OK using names that don’t start with ‘.’ is worse). I don’t ls -A my homedir as much, but what the hell are .517827.padl? Who created .android (I don’t use android and don’t develop for it) etc.

These people are arrogant shitheads and I’d like to know who they are so I can avoid their software. I assume if they do crap like this their software does other nefarious things.

Re: Dotfile madness

#66
That's why I never use $HOME for personal files. All of my files are in the Dropbox folder or another custom folder on my work PC. It's nonstandard, so no one litters in it besides me.

Re: Dotfile madness

#67
post #38

From a user standpoint, a lot of of unrecognizable things show up if you pass that -l flag. In my opinion, having a conventional place to look for user configuration in plain text is a good thing, not a bad thing, and of course I would want it to be in the directory on my system where I'm the sole owner. As somebody else mentioned, this means backing up my personal settings and files is braindead simple, too. Asking…

The other way-- and I'm sorry for how smug this sounds-- is to just not litter in your own home directory without cleaning it up. How about the other way is I’ll just stop using your product/service/business that doesn’t respect my machine?

That's my point exactly. Most of these programs have command line flags you can pass to indicate the configuration file that should be used. Doing that, and then by default putting my configuration in the most reasonable place for it--a dotfile-- is, in my opinion, the most respectful way a programmer can treat someone's machine.

Not to mention that most of these are free and open source, so building according to convention is the best way to keep their userbase happy (as fiddlerwoaroof pointed out, $HOME was the original conventional dotfile location pre-2003.)

So if your program doesn't respect my machine (meaning allow me to configure it to prevent unwanted behavior) then yes absolutely, into the bin with it. And rm -rf its dotfiles after.

Re: Dotfile madness

#68
post #3

Why do programmers do this? What thought process leads to someone thinking this is a good idea?

I developed a utility for my own use and found an answer to your question.

When the program starts up, it needs to know what its configuration is. This is not stored in the code. So it has to find its configuration data somewhere. Ideally, you'd let the user configure where they want the config file. But then the program has to read the config file to find out where the config file is, and it doesn't know where to look.

(So it seems like you pretty much have to put config data in the same place on every computer, or use environment variables.)

If you don't know about the XDG Specification in the article (I didn't), a $HOME/.myconfig file is by far the simplest and most robust solution.

Re: Dotfile madness

#69
I have been fighting this but I gave up: people just don't care or are somewhat opposed, even when presented with a backword compatible patch.

Now I just mount the home directory with rewritefs and try make the mess more or less compliant to the spec. It's not ideal: it's a hack and it causes a performance hit but I can be at peace in my ~.

Re: Dotfile madness

#70
post #21

I don't get the problem. Why bother where dotfiles are written to? GUI file managers and userland tools hide them by default. What would I gain by having them written outside of $HOME?

Many of us don’t use GUI file managers so why should our neighborhoods be considered dumping grounds?
Post reply on HN