101–110 of 214 posts
I actually just make my personal home directory in the root of the filesystem. So /me. If /root can have it, why can't I? It is my machine after all.
The second example is a nice start, but I'd really like to see invisible files/folders in ~/ done away with altogether. So starting with that example, I might add a visible ~/Library/ folder, then move ~/.config/ and ~/.local/ in there as ~/Library/Config/ and ~/Library/Local/ as normal visible folders. Same for .bashrc, .profile, etc; put them in ~/Library/Config/ without the dots.
What does Library actually mean though? ;)
Earlier quoted context omitted.
.gitignore in $HOME/.config: ``` * !nvim/ !dunst/ !i3/ ``` Then you have a whitelist which is clearly not that hard to maintain For the cache, the opposite argument is just as true: If I want to clear cache from everything to save space, I can just `rm -rf ~/.cache` instead. And this case is a lot more common than wanting to "start from a clean profile" :/
> I can just `rm -rf ~/.cache But can you? Did you really close all the apps using ~/.cache? What if some app is just doing some cleanup operation, moves a bunch of stuff to cache, and the files are missing now? Did you just delete android studio cache in the middle of a compile? You can also make a script like your .config, but it's called "clear_cache.sh", where you hardcore a few paths you usually clean manually.
Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178
One of the things that changed my life recently, that I hadn't seen before: NeoVim has a NVIM_APPNAME variable that lets you change the app name. So when I wanted to try AstroVim, I just set NVIM_APPNAME=astrovim, and dropped the files in ~/.config/astrovim instead of blowing up my existing (shitty) ~/.config/nvim. I really wish the idea of configurable appnames was a part of the spec! (or a well-known extension!)
Now let's bikeshed and scatter them randomly across several places. To make it more fun let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file. Add lots of categories to create ambiguity. Make some of the default locations single level and others multiple level directories for no apparent reason for extra fun.
~/Library/Application Support/AppName
With 3 competing standards it's unlikely that this will ever be resolved.
I have a very dumb question: why does the article use `find` with `printf` and depth specification, as opposed to the simpler `ls -a`? I'm assuming it has something to do with portability, but `ls -a` is already in POSIX. I'm a bit confused.
Hmm. I think it's because `ls -a` will not visually differentiate between files and folders and will also show `.`and `..`. and will span contents over columns while find will return a line by found items. Or they are a show-off.
ls -A -1 -p
-A is like -a but will not print . and .. directories.
-1 prints one file per line.
-p appends / to directories.
There's a lot more flags in the man page: https://man7.org/linux/man-pages/man1/ls.1.html
In what world is simply dumping config items for your app in the user's home directory sensible? Why stop at config items? Do cache or temp crap too. The thought process of persisting with this baffles me. Microsoft would be absolutely ridiculed if one day your msword preferences appeared on your desktop as an XML file, and no matter what, it kept reappearing.
desktop.iniEarlier quoted context omitted.
export GOPATH=~/Projects/go Has been like this since forever.
Being like that for a long time is not a justification for terrible defaults.
Also works better on Windows where .path is not hidden
Also it seems Rob Pike one of the creators of Go and involved with early UNIX thinks that . making hidden files was a mistake. Quote via XahLee http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_... - original was Google+ so not existing now.