Live data from Hacker News

Dotfile madness

0x46.net

181–190 of 534 posts

Re: Dotfile madness

#181
post #109

Earlier quoted context omitted.

Please no. This article is literally "Dotfile madness", don't make it worse! I have to deal already with these on file shares, specifically for Apple: .DS_Store, .Trashes and .AppleDouble, or for Windows: Thumbs.db, $RECYCLE.BIN (for some reason Windows sometimes ignores the fact I've disabled the recycle bin on a share and creates this instead) and desktop.ini. Please don't drop crap around directories where there e…

How do you have to “deal with” them? What are the portable tidier alternatives?

A daemon with a CLI and a programmatic interface, backed by a SQLite store, hooked into Linux audit and perhaps an LD_PRELOAD?

Re: Dotfile madness

#182
post #2

This isn't just a Linux problem. In Windows, the users /documents folder is polluted in exactly the same way these days.

In addition, the home directory on Windows is now populated with every kind of config file from linters to .gitconfig to .bash_history, etc...

Re: Dotfile madness

#183

Slight tangent, but I wish there was a standardized way to tell running processes to re-read their dotfiles. If I change my .zshrc, I have to re-source it in each running instance of zsh. Sure, I could automate this. But I'd also like the same done in vim. And in weechat. And in mpv. And in everything using GNU Readline... you get the picture. This is probably at the top of my list "biggest complaints that won't be r…

Some programs (I can think of Termite and Kitty) use the USR1 signal to this end.

Be careful. Some programs terminate when sent USR1.

Re: Dotfile madness

#184
post #170
post #89

Earlier quoted context omitted.

I just keep my home folder in /etc/username and use this construct: (just an example, not actual) environment.etc = { "qemu/bridge.conf".text = ''allow br0''; "username/.inputrc".text = '' \$include /etc/inputrc "\e[A": history-search-backward "\e[B": history-search-forward set show-all-if-ambiguous on set completion-ignore-case on ''; }; to write configs into /etc proper and my home folder.

Hmm that's way radical than I thought. If I understand correctly, this is a read-only home folder. Would be interesting to use, I'll give it a try.

It's not read-only, but you need to reset the rights on it if you delete and rebuild it (chown probably can be put here https://nixos.org/nixos/options.html#activationscripts)

I haven't used home-manager, but it looks like a bloated thing that I don't need in my life.

Re: Dotfile madness

#185
post #78

Would exporting HOME to something else (eg the xdg root/appname) prior to invoking programs solve this problem for most apps without code changes?

XDG has different roots for configuration, cache, and data files.

Re: Dotfile madness

#186
post #174

Earlier quoted context omitted.

Associating tags with files is straight forward. What's not quite so straight forward is how you query the system. The worst implementations of file tagging only implement retrieving a list of all files that have a given tag. Slightly better than this are tagging systems that will return the intersection between two or more tags. Most tag systems never go beyond this. Going slightly further, tag exclusions are powerf…

I very much agree. This would require a ton of difference from how modern desktop and mobile OSes handle files / documents. Maybe some time later, some research OS would implement it.

I've implemented the above in userspace for my own experimentation (not yet ready for public release, but maybe soon.) Nearly everything I've described above can be implemented with relatively straight forward SQL queries and SQLites performance has been everything I could have asked from it (in the neighborhood of ten thousand tags and hundreds of thousands of files.)

Getting file tagging into the kernel level to replace directory hierarchies would be a huge paradigm shift, a very dramatic departure from Unix. To be honest I'm not sure whether or not getting such a system into a kernel would be appropriate or not. Traditional hierarchical file management seems more than sufficient for "system files". But I'm really interested in replacing hierarchical file management from the users' perspective. More or less, put ~/Documents, ~/Downloads, ~/Desktop, etc under control of the tagging system but leave the rest of the system as-is. At least for the proof of concept.

I think a demonstration system could be implemented as a custom desktop environment running on regular old linux, where the open and save dialogs of GUI applications have been replaced with tagging/querying windows. Instead of the user clicking through a few directories to find a file to open or find a directory to save something, they would instead click or type in tags to add or query. The GUI file manager would likewise be replaced with the GUI frontend to the tagging system.

Re: Dotfile madness

#187
Not sure what the problem is -- dotfiles or other application files need to be somewhere, whether in the home directory or somewhere else (that the OS doesn't enforce but just requires by convention) makes no difference. What would really help is what another comment mentioned -- the ability to tell which modules owns a particular file -- that would be really cool.

Re: Dotfile madness

#188

To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't b…

I use ubuntu 18.04 (kde) and my snap folder is /snap I don't know how I did this.

I am using snap on Arch and my snap folder is /snap as well.

Re: Dotfile madness

#189
post #109

Earlier quoted context omitted.

Please no. This article is literally "Dotfile madness", don't make it worse! I have to deal already with these on file shares, specifically for Apple: .DS_Store, .Trashes and .AppleDouble, or for Windows: Thumbs.db, $RECYCLE.BIN (for some reason Windows sometimes ignores the fact I've disabled the recycle bin on a share and creates this instead) and desktop.ini. Please don't drop crap around directories where there e…

How do you have to “deal with” them? What are the portable tidier alternatives?

Because when you have multiple OSs accessing the same shared folder, they all create their own crap, which is then visible to the other OSs, and fills up directories with stuff that confuses normal users.

Re: Dotfile madness

#190
post #137

Oddly I feel completely the opposite about this topic. I think dot files in your home directory are exactly the way to go. Using the XDG standard leaves you with whatever the distro decides is the correct location for these files. While their recommendation is all in the home directory, I wouldn't put it past some of these distro developers to make some crazy /var/users/{uid}/config directory. This is important when…

Yeah, when I got to this:

To those of you reading this: I beg you. Avoid creating files or directories of any kind in your user's $HOME directory in order to store your configuration or data.

My immediate response was pretty much "where the hell else should they put them then?"

What exactly else is the /home dir even for otherwise?

The purpose of home is for user-level persistent files. Giving it access to something else means giving random programs write access to some global part of the file tree, and I'd rather not allow that except when actually necessary. As it is I hate having stuff that manual installs in /opt, or the way too many programs on Ubuntu are configured to require sudo to work.

I'm actually totally on board with more stuff that installs entirely local only, especially if it's from outside the distro's package system. I don't like stuff mangling the global tree with no clear standardized path for removal and uninstallation. At least if it's in /home, I can just delete it myself without even needing to go sudo.

And the purpose of .dotfiles in /home is because it prevents those user configuration files and other such local data from cluttering your directory when doing a plain ls for regular user files.

This article just sounds like a misunderstanding of how the file tree is even supposed to work.

Post reply on HN