|
FreeBSD General Other questions regarding FreeBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|||
Where can I put dotfiles?
Ok, this might be more of a UNIX question but I have a user on my main desktop that is several years old, has been around since FreeBSD 3.3 in some form or another and has lots of .files and .folders.
Its more of an annoyance than anything else. Some of them, like .doom3 and .quake fore are VERY important.... license keys hehe. Is there some kind of env variable that will cause the system to save and look for dotfiles somewhere else? it would be nice to put them in a separate folder and not in the main home directory. |
|
||||
Modern convention is to use the XDG_* environment variables, this usually leads to something saved in ~/.local/share/ instead of ~/.whatever.
Sadly many programs don't do that and still use ~/. Someone should've arm twisted something like that spec down unix programmers throats 20 years ago. So you're basically toast.
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|||
I'm generally not fond of the ~/.local convention, just seems out of place.. especially considering the amount of software creating their own directories.
|
|
|||
I never knew the ~/.local/share thing was a convention hehe. The number of applications following it is so infinitely minuscule. And there is ~/.config too.
I never understood why they did not simply replicate the system's hierarchy, for example ~/etc for the configuration files. I find ~/mnt and ~/bin very useful. Now, the maintainers could make patches that would replace all $HOME/.appname/config instances with $HOME/.local/share/appname/config or whatever, like they do for other things when they port the application. This is really a mess, but see the bright side: we have no binary registries that span tens of MBs.
__________________
May the source be with you! |
|
||||
It's not convention, it's the defaults mandated by the standard. Following the standard... is just advisable.
If the normal is to use ${PREFIX:-/usr/local}/share for system wide shared data, then using ~/.local/share sounds like a good idea to me. I do however feel that $XDG_CONFIG_HOME should default to ~/.local/etc instead of ~/.config, or at least make the default for $XDG_DATA_HOME match it. Then again, I also think that $XDG_CONFIG_DIRS should default to /etc/ instead of /etc/xdg... but I didn't write the bloody standard ^_^. If by convention the files are normally hidden, cluttering the home directory with unhidden folders or even a ~/local directory would be equally counter productive, as making it ~/foorc instead of ~/.foorc! At first, I did not like the whole XDG base directory crap, and I still think it has faults (^). But experience has shown me it is a lot better than having 30-40 dot files and folders littering my $ ls -a output, except when I am looking for old dot files to be removed. There should also be a make target/pkg_delete option for doing that from the package database, or whatever the OSes package management system is. Yeah, I'm lazy of finger.What would be nice is if upstream projects would be willing to accept such patches to their source and documentation, even if all the work came from downstream. I fear however, many projects would simply say "No" or be unreachable for comment. If project maintainers would accept them, I'd take a few months to patch as many apps as I could...
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|||
Thanks for the replies. Looks like Ill have to read up on XDG.
|
Thread Tools | |
Display Modes | |
|
|