Dotfile madness
61–70 of 534 posts
Re: Dotfile madness
#62~/etc would have been so nice.
Re: Dotfile madness
#63Why do programmers do this? What thought process leads to someone thinking this is a good idea?
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
#64From 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…
That place is $XDG_HOME_CONFIG (~/.config)
Re: Dotfile madness
#65These 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
#66Re: Dotfile madness
#67From 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?
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
#68Why do programmers do this? What thought process leads to someone thinking this is a good idea?
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
#69Now 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
#70I 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?