If anyone would like to actually force the non-compliant applications to do the thing correctly, then xdg-ninja is your friend [0]. The script looks at all the dotfiles in the home folder and tells you what environment variables you have to set to make them follow XDG base directory specifications, in the cases where that's not possible it will show you the related GitHub issue or similar bug tracking option with the problem.
My current dotfiles [1] already have a lot of these and they mostly just work. Once in a while an application won't respect it completely, and so instead of having a mess with xdg + whatever the dev though was cooler I just let the application do it's thing so at least is somewhat predictable.
Hah I was literally just complaining about applications not following the XDG directory spec today.
there's a non-exhaustive list of applications on the archwiki [0] that put their config/data in dotfiles in the home directory. surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce. a Reddit thread has some list of issues where the change is brought up [1].
The dotfiles and dotfolders directly in the home folder is "the way it was always done", and now some "new kids" came and want changes done to software which has existed before they were even born. People have muscle memory for those folders, some have hardcoded those paths in other scripts, others just don't care, and things stay as they always were.
On one hand, it's great to have all the stuff in the same place, on the other hand, we used to have this, before the ~/.config folder too.
Also, it's not just in one place anymore, but in many places -- so to completely remove a programX, it's not enough to just remove ~/.programX, but you need to remove a folder from ~/.config/, and another one from ~/.local/something, and another form ~/.cache,...
So yeah, i understand 'the old guys' too... maybe because i'm not 20-something anymore.
If we want to flex gray hairs, the idea that an application should put it's configuration files in dotfiles cluttering the home directory is regarded as a mistake by the people who are responsible for it.
Obviously, we are now stuck with dotfiles as a "feature", but that doesn't mean we need to have more of them than necessary. Cluttering the home folder with a disorganized mess of files with different modalities next to eachother is ridiculous, pointless, and a collective waste of time.
Almost all of the apps people are complaining about not following XDG were created long after the XDG base directory specification existed. It's time to move on.
P.S.: it'd be preferable also if it wasn't simply implied that everyone who's been around Linux/UNIX for a couple decades hates change. Churn for the sake of churn is bad, but churn is not all wasted. Standardizing once-disorganized directory hierarchy is certainly not a waste of time.
The really fun part is when you have a program that has ~/.programX, but also ~/.programXy, ~/.programX_cache, ~/.programxrc, ~/.programx_init, ~/.programx/a_whole_directory, ~/.otherthing, ~/.maybe_a_database_for_good_measure.sqlite, ~/.and_the_kitchen_sink_too. And that's not even getting into questions like "can I nuke ~/.programX_db to clear the program's cache without losing my configurations?". I agree that the XDG spec isn't an improvement for programs that have _precisely_ one config file, but it's a _major_ improvement for programs that need multiple config files, config directories, separate configs and caches, and more, and it's not a _regression_ from single-file configs.
That's why that kind of software uses a .programX directory, where everything like that can be put in.
Look at ~/.wine for example... config files, whole C drive, everything in one simple folder. Want to upgrade to an alpha version to test something, but don't want to break anything that's now working? Just backup that one single folder. Restore or migrate configuration to another computer? One single folder. Remove any trace of that app? Again, one simple folder.
Want to do the same with google chrome? .config/google-chrome... oh wait, what if there's something in .local too? Still doesn't work? Oh wait, you forgot the .cache directory, and have been loading an old version of something.
Backups are the main reason why I want programs to follow the XDG Base Directory Specification. I don't want my backups to includes gigabytes of files that should be in ~/.cache, which is a directory I never back up. The shell script that I wrote to back up my PC includes dozens of rsync exclusions for files in ~/.mozilla, etc. that should be in ~/.cache.
> Look at ~/.wine for example... config files, whole C drive, everything in one simple folder
Except it isn't really. Just a few days ago I tried to purge Wine from my system. Uninstalled through pacman, cleaned up orphaned dependencies. Killed the ./wine folder and various other leftovers too, because depite your claim, there they were, though I didn't commit to memory exactly where and what. Removed some autostart shortcuts, cleared a few icons from desktop, and manually edited the Plasma menu to remove some stubborn links.
And yet ... I still get suggestions to open my jpg's and png's with something called Wine Internet Explorer. Which i don't really believe is distro specific, since I've seen the same thing happen in both Debian and RedHat derivatives.
If you ever want to prevent this integration from happening in the first place, you can do it by editing the registry in a given wine prefix. You can run regedit with the usual command, `wine regedit`, then locate the key:
Set it to empty to disable the integration entirely. Or, just remove the `-a` switch and you will still get desktop icons, just not file associations.
It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it, since those various files need to be in their respective locations to reasonably be picked up. (Maybe it could use symlinks instead, but even if it did, they'd need to get cleaned up by something when the target gets deleted.)
> It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it
There is a way around unwanted and unexpected associations though: make the integration opt-in instead of opt-out and/or filter associations that the user is unlikely to ever want (like standard file types that will almost certainly already be handled outside Wine). Wine's Internet Explorer is there for compatibilty with Windows programs that expect IE, exposing it outside the Wine environment does not make any sense.
Since I use multiple prefixes, including temporary ones, editing registry in each one of them is not an option so I have my package manager set not to install winemenubuilder at all.
I believe another approach is to edit the default registry settings in /usr/share/wine/wine.inf so that new prefixes have the desired setting. Of course, then when updating the package it has to be reconciled. But it does have the advantage of being able to allow e.g. the settings that would only produce launcher icons and not file associations. There's another method using environment variables too, though I think that one basically works the same as removing the package entirely and can't be used to customize the behavior.
I kind of agree with you that the defaults are not great, or at least if things haven't changed. We could always see if maybe they'll accept patches to filter out more stuff by default.
This is probably because Wine created a .desktop file in the directory for registering default applications. I don't remember what the directory path is but your package manager is responsible for it, not Wine. They can't put it in .wine because it's a standardised location.
If you have a mass of cached data that shouldn't be backed up would you rather just exclude .cache or investigate what files/directories every individual app uses.
> That's why that kind of software uses a .programX directory, where everything like that can be put in.
You mean, this is why that kind of software should use a .programX directory. Evidently many don't. And of you think about doing it, just move it into .config for good measure...
Crap like wget just keeps shoving files directly into my home instead. When they added hsts support they had the chance to finally create a directory, ideally in .config, so if they need to add even more files in the future they wouldn't have to clutter $HOME even more. But no, that would be too forward-thinking. Just put the hsts file in home and be done.
The XDG base directory specification[0] was initially introduced in 2003; 20 years ago now. Yes there's plenty of software that existed before 2003 which didn't respect XDG, but most all of the Linux software dumping dotfiles in my homedir where written not just after 2003, but many years after 2003. For example, the following pieces of software all have dumped garbage in my homedir, and all are much less than 20 years (or even 15 years) old:
There's no excuses for these programs not respecting standards that are 1. Well established by the time the software was written and 2. short (seriously, the standard's contents fit entirely on three A4 pieces of paper)
> There's no excuses for these programs not respecting standards that are 1. Well established by the time the software was written and 2. short
This isn't a standard, it's a convention at best. A freedesktop.org specification. Basically a scheme Red Hat people thought up and implemented widely in the open source software projects they control. It may be a useful abstraction but there's absolutely no obligation to conform to it. There doesn't have to be an "excuse" or any form of justification at all. "I just don't like it" is enough. I don't like those unsightly XDG variables either and it's entirely within my power as a software developer to trash the entire concept of XDG and do things in any way I see fit.
This is the world of Unix, there's very little obligation to do anything other than convention. That's technically true, just like you can write your software to ignore all signals, or write your software such that it assumes it's always run as root for your convenience. That may be more convenient for you the developer, it's true.
But those are all generally poor ways to write software, and a great way to get your users to complain. So it is with ignoring XDG.
To put configs in ~/.program is the convention I learned, not ~/.config/. That came later, and I see 0 reason to pick it up. It's an annoying new hierarchy which I don't even like as a user, so I certainly wouldn't follow it as a developer.
If the programs in question implement the XDG base directory spec properly, then putting `export XDG_CONFIG_HOME=$HOME/.program` in your .profile will make them put config files in .program, not .config.
Sure, XDG was introduced in 2003, but why would you expect developers to start to follow its rules instantly? At best, it started to gain some traction 4 or 5 years after that, but still today, it is far from universally accepted.
But take a step further back: why should anyone care about what the XDG says in first place? This isn't a dictatorship, and things were doing just fine long before a handful of people who wrote the XDG thought their ideas were the best approach.
It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy. The fact that the XDG file layout still isn't universally used suggests it doesn't have as much value as its proponents think.
> But take a step further back: why should anyone care about what the XDG says in first place?
Because their users are asking them to not pollute the home directory? This isn't bikeshedding config locations without reason, there is a clear motivation for letting users a) specify where data should go and b) separate different types of data.
> It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy.
The XDG basedir spec has been adopted broadly amongs many organizations and individual devlopers including all major desktop environments. It is not adopted universally yet, but few things are.
But why should developers conform to that specific standard, if (for them, and many of their users) it makes more sense to use a "~/.wine" (or whatever other) folder?
If i want to completely remove wine from my profile, how many folders do I have to delete doing it the old way? One - ~/.wine. How many using the new? One in .config, then .local/share, probably one in .cache... oh wait, .local/state too.. Probably.. well, maybe, I'd have to check manually. Same for other software. One folder to remove, one folder to backup, one folder to restore.
Following the standard does not require you don't have a single folder, it can all be changed with 4 simple environment variables. If you want to have everything dumped horrendously in your home folder nothing is saying you can't, it just wouldn't be the default, because it's simply not an orderly way to organize the files.
The biggest problem is programs that don't even let you change where they store the stuff, so even if you're okay with the default not being XDG you dont even have the option to make it respect XDG base directory specification.
Whenever I install directly instead of using e.g. apt (typically because I want a more current version than the distro has), I use GNU stow [0], for precisely this reason. It works at the system level, at the user level, within projects, wherever. A simple "stow -D" is all it takes to clean out all the directories.
There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.
There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable $XDG_CONFIG_HOME.
Neither of those environment variables is defined on a stock Ubuntu 22.04.1 LTS.
$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.
$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored. If $XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used.
I like this system overall, but this particular aspect seems like a mistake [0] to me. Instead of a simple rule like "use these envars", it has this more complicated logic that must be replicated in all apps supported by all developers. Users would have more agency if they could inform apps of their preferences by simply setting some envars. [1] If this simpler, more user-friendly regime had been in the spec, we would have seen better adoption initially and also two decades later.
[0] of course one shouldn't assume that a totalitarian decision is a mistake, because it's just as likely that the decision-maker has priorities other than "support users"
[1] yes of course users have agency with respect to where XDG is implemented, but the simpler rule would also have given them agency with respect to whether it is implemented
And the variables should not be set if the user/distro wants the default (probably to force developers to handle the default case which is needed for compatibility anyway).
Right now I have in my home folder 4 undesirable dot something which should be somewhere else and I can't change it. Meanwhile, I have 63 folders in my .config which means most of the applications I'm using do respect the XDG base directory specification, only a few entitled or extremely legacy ones don't.
.SpaceVim.d - My fault, I should write my own vimrc but I'm lazy
.steam and .steampath and .steampid - Steam
.vscode-oss - VS Codium
.w3m - w3m cli browser
These are the ones I couldn't change the behavior of, in my dotfiles I've managed to fix at least a dozen of programs that were previously misbehaving but offered environment variables to change their behaviors.
The thing that bothers me most about these is that most of these folders are simply cache and logs, I can always delete them and the application will keep working, but of course the folders will be recreated. It's truly mind-numbing.
# Save shell wrapper as '~/.local/bin/firefox'
{ while kill -0 $$ 2> /dev/null; do rm -rf $HOME/.mozilla; done; } &
/bin/firefox --profile $XDG_DATA_HOME/firefox $@
NPM
# set env variable
export NPM_CONFIG_USERCONFIG=$XDG_CONFIG_HOME/npm/npmrc
# and in npmrc:
prefix=${XDG_DATA_HOME}/npm
cache=${XDG_CACHE_HOME}/npm
tmp=${XDG_RUNTIME_DIR}/npm
init-module=${XDG_CONFIG_HOME}/npm/config/npm-init.js
Steam
Steam actually creates only symlinks for backward
compatibility as some games (may) expect them in $HOME.
You can safely launch it with modified HOME variable:
$ HOME="$XDG_DATA_HOME/Steam" steam
(and/or put it into a wrapper script like with Firefox)
Vim
I don't know how it's with SpaceVim,
but with regular vimrc you can make it follow the spec:
https://blog.joren.ga/vim-xdg
What the hell you may have just changed my life. The NPM one I was aware of through xdg-ninja but last time I tried it didn't work because I also use nvm which doesn't support that, honestly not an issue with NPM, I should've noted in the comment. The Steam one however is a total life-changer, if I ever find you in the street someday remember me I owe you a beer (or some non-alcoholic beverage of your preference).
I don't see the problem. There's no reason to choose one or the other when we can have both. Many programs try several options. Git for example tries ~/.gitconfig and ~/.config/git/config.
Do people seriously resist such non-destructive improvements just because they think it's offensive when younger programmers have opinions on legacy software?
Personally I see a lot of young people use emacs and BSD licences, but because I'm an older engineer and have the wisdom and experience of time, I use vim and GPL.
Another man with the wisdom of ages, irrespective of the date of your birth. Your choice of text editor reveals that you must also be quite good looking.
I'm also a Vim user; in my Vim wisdom and experience I made it follow the damn XDG spec; if hidden files are a feature, I want it to be a feature for my use-cases, not program clutter.
I use nvim like the user (backers.md baby!) so I get to use `master` with `~/.config/nvim/init.vim`. Of course, I also donated to Bram's Ugandas or wherever, so I think you are a wise and attractive person. Your choice of actions reveals that your soul is deep and beautiful.
> Also, it's not just in one place anymore, but in many places -- so to completely remove a programX, it's not enough to just remove ~/.programX, but you need to remove a folder from ~/.config/, and another one from ~/.local/something, and another form ~/.cache,...
OTOH if you want to completely remove your cache, or completely backup your config...
I realize that you wrote "new kids" in quotes, but these "new kids" might have grandchildren at this point given that the initial draft of the XDG Base Directory Specification was published in 2002.
I'd say bashrc and profile and friends are one of the few examples in which using hardcoded paths is OK. Same with SSH, GPG, and PAM.
But when people are talking about compliance, and hardcoding very few people are talking about those applications - there are hundreds of other applications do the wrong thing, and some scripts hardcode things as a result.
No, but don't keep doing it that way for new software, or even new files. You existing config file is in ~ because it's 30 years old. Fine.
If you get to the point where you need another file for something, put it in a directory under .config so whenever you need to add even more, you don't keep cluttering my home.
As a defence of hardcoded paths might go, I could've done better myself. What else from your OS 30 years ago might you keep just because it's 30+ years old?
I keep it because it's worked for 30 years without issues and it's still working. Must you always replace something, just because a newer thing is "out there"? On the other hand, this is hackernews, and rewriting everything, from a text editor to a file browser, into a <language of the week> (ruby, go, rust,...) is a thing.
Try moving all of those directories and files somewhere else that you would prefer and then see which programs break, which apps and libraries won't install, and then wonder why hardcoding is something the devs for these projects cling to.
To be pedantic, if we're going to cite Unix history, then technically there is no such thing as a "hidden" file. As I understand, the original implementation of tools like ls would not show the current directory "." in the listing. The quickest way of doing this in C was checking whether dentry.name[0] == '.'
This also had the side effect of hiding entries that had names beginning with ".", and over time an implementation bug/quirk became accepted behaviour, and was post-hoc rationalised as "hidden" files.
Considering the spec is 20 years old, having "muscle memory" is a bit of a weak excuse at this point.
Having a couple of directories to clean up is a bit annoying, but they used to stick the config file in your home and then make an application directory so we were already having to deal with multiple locations.
Can I also soapbox about the XDG_CONFIG_HOME (~/.config) folder having gigs of temp data in it?
(I'm looking at you, Slack!)
How awesome would it be to be able to back up my custom app configs just by copying around one tiny folder? Or throwing it in a git repo and knowing what config changed when? :\
a bunch of windows stuff does this too putting config in appdata/local and huge cache assets in appdata/roaming.
anything that depends on good behaviour is doomed imo like Google wave circles
Yeah. It annoys me to no end that the new powershell didn't take the opportunity to move the config out of My Documents and into roaming app data which in theory is where that sort of file should be.
It's things like that which have made me give up on %USERPROFILE% (and to a lesser extent $HOME), and I now put my files that I care about into a completely separate folder outside of the normal hierarchy.
Oh, it's really not anything impressive. I've just decided to treat %USERPROFILE% as for machine generated files only. I then have a new directory on C: where I put my documents/projects/etc (all in appropriate sub folders).
My config files are a bit more interesting, and are stored in a chezmoi[^1] repo. If I tinker with a program enough, I generally move its config into there so I can keep track of it and the changes (to make this easier I have a bat file in shell:sendto to add files/folders to chezmoi).
Thinking about this, I should probably move the chezmoi repo into my personal directory, and symlink it back to it's normal location.
Should've kept Slack in a containered in a browser tab where it belongs so it can't go messing with your system or prevent you from blocking their tracking.
And then I've seen websites hoggi g gigs of local storage after you visit them once a blue moon. The trend is blatantly towards no optimization whatsoever. Apart from profits and squeezing the last drop off your customers by any means necessary
One of the best things about no longer using macOS is not having to fight 'but Application Support/Resources/Nonsense/Foobar.app/Resources/config is the standard location on this platform!' ... The XDG base dir spec makes a lot more sense even on macOS for developer tools, but I'm glad not to have to worry about that any more.
On Linux that excuse is gone, so it's just either 'oops yes will fix' or 'agh, sorry, legacy'. Nobody (that I've ever seen) tries to claim something else is fine or better.
I mean, from the perspective of a person that hasn't heard about it before, this is just another standard[0].
I opened your links. There's no easy way to judge the traction or popularity of this. Why do you think maintainers should just apply another standard that's thrown at them?
I don't mean to be dismissive nor criticize the standard itself. I'm trying to give you a glimpse of what a person that hasn't heard about XDG before sees, when they open your links.
Yes, sticking everything into `$HOME/.toolname` is what most cross-platform software is doing, and I imagine that's just fine for the vast majority of users.
Short, memorable passwords like one's birthday or favourite pet's name are "just fine for the vast majority of users". It's a meaningless metric of quality - or more to the point - it isn't a metric of quality.
1. It doesn't separate program's config, data, and cache; so it is impossible to backup excluding cache, impossible to reset your config without data-loss.
2. It assumes home is infinite, if you are running out of space in home you can't move program files to other partitions. E.G. Flatpack hardcodes its apps data in `~/.var` so if you have a small/almost-full home partition you simply can't install certain Flatpacks.
First and foremost, that I don't get to decide where things go on my own machine, and that if I do regardless, because developers didn't follow a simple standard and instead decided to hardcode things that shouldn't be hardcoded - which is just about the first thing every dev is taught not to do - things will break.
You may not find it important but is it an issue or not?
Except it isn't most cross-plaform software doing that. It might be most of the cross-platform software you use but IME it's mostly it's corporate software plus a few holdouts too stubborn to add two lines to the code reading their config file.
> surprisingly, there's also lots of pushback from maintainers of projects who don't want to change this, for whatever excuse they can produce.
There doesn't need to be an "excuse" though. "I don't like it" or "I don't want to do it" is more than enough. They're the ones maintaining the damn things, the least we can do is respect them. They don't really need to justify anything, acting as if they had to is how you get pushback. They probably deny you just to prove that you have no power over them, because you insinuated otherwise with words like "excuse".
> They're the ones maintaining the damn things, the least we can do is respect them.
we don't respect maintainers who leave in buffer overruns or x-site scripting, why should we respect maintainers who don't respect users? yes, they're writing and maintaining, but undoubtedly also using tons of respectful opensource that other maintainers take care of.
it's like driving a car ("everybody faster than me is a maniac, everybody slower than me is a moron") and cursing cyclists, then jumping on your bike and running red lights, stop signs, crosswalks, sidewalks, you name it. To have a civilized society we all have to go out of our way a little bit for other people, throw away some trash that's not yours.
like forum/reddit moderator phenomenon, there is something about the power (and most definitely the nagging they get from impolite users) that makes the developers act like douches when they probably aren't the rest of the time.
but that's not an excuse for crapping all over my dotfiles and home directory tree.
> why should we respect maintainers who don't respect users?
Saying that using dotfiles instead of ~/.config means they "don't respect users" is a little dramatic, don't you think? Like it or not, unix has historically treated dotfiles as "hidden" and nobody expects you to get upset that they created a hidden file in your home directory without your consent. It's not really about respect, it's just convention you apparently don't like.
I currently have 60 dotfiles in my home directory and probably deliberately created less than 10 of those. The fact that anyone would be upset by this is news to me and most likely is news to a lot of the developers that created these things: cargo, dbus, docker, gem, gnome, gnupg, gphoto, java, kde, maven, mozilla, osquery, rpm, rustup, ssh, vagrant, vim, vscode, wget, yarn, zoom. Not that "this bad behavior is widespread" is a good excuse, but the point is that I don't think the world is at all in agreement that this is "bad behavior."
Just to clarify, it is not just about "hidden" files looking good. There are many reasons one may want to move config/data/cache files to other locations, E.G. in my case I have a computer with home on a small partition that simply can't fit all the crap those misbehaving programs try to put there. I simply can't install Flatpacks on that machine because they obviously won't fit in a small home and can't be moved because of a maintainer who is very disrespectful to users (the bugs full with messages of users pleading for him to allow them to move apps to other partitions is disheartening).
> Saying that using dotfiles instead of ~/.config means they "don't respect users" is a little dramatic, don't you think?
No I don't think so. For many applications (i.e. only config, no cache) it's literally an additional getenv and minimal logic when opening your config files. No additional dependencies needed. The amount of effort required is tiny compared to the benefit multiplied by the number of users that don't want dotfiles in their $HOME.
> we don't respect maintainers who leave in buffer overruns or x-site scripting, why should we respect maintainers who don't respect users?
Because they're the ones putting in the work. I could patch all the programs to use whatever paths I liked best if I really cared but the truth is I don't want to put in that much effort. So I just work with what I'm given instead.
Besides, dotfiles conventions are not even in the same category of technical decision as literal vulnerabilities. One puts people at actual risk, the other is just opinion on file system taxonomy.
I mean, I have opinions on proper file system organization too and they certainly don't match Unix "tradition" but I don't go to other people's issue trackers and shame other developers when they make "excuses" for not following whatever scheme I thought up. I have reasons and I can certainly try to convince others that I'm right but it's simply offensive to show up out of nowhere with an indignant tone demanding that others make changes of a subjective and frankly trivial nature and then criticizing them in other forums when they refuse.
I hate when applications ignore the XDG spec, but you know what I hate more? the XDG spec!
I don't want all my pictures to go in Pictures, all my documents in Documents, etc. I want everything from each project to go in the directory for that project. I don't need it to read my mind, but when I save a document to a new directory and then I want to save a spreadsheet too... I want that new directory to be a top-line choice, but I want the old directory there too.
Doesn't everybody work like me? (asking seriously)
and hey, call me a freak, but I still get the odd sort of picture that I don't want showing up on the lock screen screensaver
What are you talking about? When people say the "XDG spec", they are usually referring to the XDG Base Directory Specification, but there are other specifications from XDG - are you talking about a different one?
Because the XDG Base Directory Specification does not dictate about how files should be saved - whether in Pictures/, Documents/, or anything else...
Also I hate localized XDG directories. Windows and macOS don't localize real directory name but only Linux does. I run LANG=C xdg-user-dirs-update after I install Linux with my lang
Windows just localizes how it shown on Explorer (and have API to get localized name), so real path is still C:\Users\user\Documents . macOS does the same thing by the way as you wrote. I don't think it's a problem.
Only XDG based systems use real /home/user/ドキュメント (in Japanese) directory . This is annoying. Please localize it well as Win/mac does.
Right, I still remember programs blowing up because they expected C:\Program Files and then encountered C:\Programme - that one at least got better when WoW64 forced the issue for english-speaking devs.
I don't think there is a spec dictating that the default location for saving files needs to depend on the file tile - which program is doing this? I think Firefox remembers the last used path per file type, even across restarts.
The Desktop, Downloads, Pictures, etc. directories themselves are not from the XDG Basedir spec and not set by XDG_ environment variables but instead in the $XDG_CONFIG_HOME/user-dirs.dirs file. I also find these less useful than the more generel data/config/cache dirs and have most theme set to my home directory - perhaps that is affecting how Firefox works?
hypothetical, but, could easily make a script that, upon cd, checks all above directories for `.xdg-root`, and while inside, has envvars set to use said folder as a root for Documents/Pictures/Etc folders
not a terrible idea, has some good points, but gui apps don't cd in a way that can be hooked, and usually i get around to popping a terminal window after i'm working on a project rather than before. (also, cd isn't so easy to script, I'd have to use a bash function, but i'd probs have to make a up new name to get used to, cdproj or something, otherwise any "headless" scripts would be do it too
And I frequently jump from desktop to desktop for multiple projects, and my terminal on that desktop is likely to already be where I want to be. Do gui apps reliably reload xdg all the time, or only at startup?
anyway, keeping it in mind, it might just be worth the trouble to click a scripted icon on each desktop :)
The Desktop, Downloads, Pictures, etc. directories are not from the XDG Basedir spec and not set by XDG_ environment variables but instead in the $XDG_CONFIG_HOME/user-dirs.dirs file. I also find these less useful than the more generel data/config/cache dirs.
It's a simple command that shadows the binary names you want with a wrapper in ~/.local/bin/ that calls the original binary after redefining $HOME to be somewhere else (by default inside ~/.local/share/fake-home/).
So if you have a program foo that dumps stuff in ~/.foo, then running `fakehome-banish foo` will create a symlink "foo" inside ~/.local/bin/evil-software (which is added to $PATH) that points to "fakehome".
"fakehome" is a simple wrapper script that, busybox-style, gets the binary name that it's being called as ("foo"), and then sets $HOME to be ~/.local/share/fakehome and calls the original foo binary.
AWS an interesting example considering it's also a default search path for the SDK so anything using an AWS SDK is going to check for ~/.aws/config; does boxxy apply the rules to anything run in a shell, or only if 'run by boxxy'?
Would be cool if there was a tool that could detect that configured path was attempted to be opened, and redirect the open() syscall to the real path... But that would most likely require kernel support.
I actually attempted using ptrace to rewrite syscalls first! It was... horribly painful, and didn't work anywhere near as well as the bind-mount version.
In the past I used something like inotab to use an inotify-based trigger to pipe data from SSH to a different system that didn't have any NAS or SAN support, it might also work to detect 'who' is touching any files that boxxy has previously seen rules for.
Perhaps still too tricky to make it do magic things and break programs in the process, but it could be used to audit who's working with what paths and let the user print a report so they know what apps to boxx up and make them behave.
That is an excellent idea! Something like could definitely be worth adding. It's why there's a "remount rootfs as ro" flag; that way anything not specified in rules is ro and misbehaving programs will explode.
For a structured approach to ptrace/syscall rewriting, you could try FB's reverie. I worked on and used it during an internship a few years back; it's pretty amazing at what it does.
I suppose that is indeed more trouble than it's worth. As for applications that might behave like AWS and their SDK; I think that if someone uses boxxy they would probably also remember to do the same thing for other stuff that uses aws under the hood, so overall a win either way!
This seems like a great idea, thank you for sharing.
Are you aware of any notable caveats to using Boxxy, given the mount-based implementation? E.g., will this continue to work if you sync ~/ with other machines (rsync, FTP, SyncThing)?
In my experience doing weird things with mountpoints, there is almost always some bug that happens on reboot of the system. For example, if your mounts aren't in /etc/fstab, they simply won't be restored.
And if you have a script that sets them up manually, then make sure that script runs on boot after any mounts it implicitly depends on.
Also note that any scripts with config stored in these mountpoints (which seems to be the point of the tool) will not be able to run until the mountpoints are up. That seems like an obvious observation, but it's easy to fall into a trap where one of your scripts installed with this tool is called in a setup script that runs on boot of your machine.
I remember when the GNUStep people thought their software was important enough to create `~/GNUStep`. Fucking maddening. Especially when one did not actually use GNUStep but some dependency.
There have been some bad ports of Windows games creating ~/My Documents lol. AFAIK there's also ~/snap. You'd think at least such non-hidden hardcoded directories would bother the developers themselves.
While reading more about this I found out about the ~/.hidden file which I'm pretty excited about. The following hides the folder from Thunar & Dolphin (and presumably other file managers):
> I recently had to use the AWS CLI. It wants to save data in ~/.aws, but I don't want it to just clutter up my $HOME however it wants. boxxy lets me force it to puts its data somewhere nice and proper.
- they could have used AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE.
But you shouldn't have to — that's the point of the complaint. That's like saying that if your neighbor is dumping toxic waste in your yard, you can always ask them to stop. Sure, but maybe they just shouldn't do that in the first place.
If you could find a way to somehow intercept without requiring aliasing, this would be amazing.
Also, as it is, isn't it problematic that programs might call others (outside of your shell, not respecting its aliasing).
A neat semi-solution (still worse than transparent interception if somehow possible) would be to have a boxxy-run script sym-linkable from ~/whatever/bin/aws (say) that basically just executes `boxxy "$(basename "$0")"`. So you could just symlink the same script with the name of whatever command you wanted to 'boxx'.
Perhaps a better solution would have been not using the Linux namespaces but using LD_PRELOAD to preload a shared library to intercept all the FS-related API and normalize the path. Of course more complex and would only function for dynamically linked executables, but would have not required to launch the executable with a proxy and would also be more stable, not relying on not so stable features such as Linux namespaces.
Update: the tool didn't help. It complains about being unable to run some SUID executable that Chromium calls. I'll have to keep removing the Downloads by hand then after each use of Chromium.
It creates a new mount namespace, and bind-mounts your ENTIRE filesystem into it, before chrooting, so that it can optionally remount / as ro to prevent applications from writing outside of the desired directories. The namespace is to allow doing the bind mounts in the first place.
I don't use macOS often-enough to know for sure, but a quick search suggests that bind-mounts (or similar) are more complicated on macOS. Not against the idea tho!
Edit:
> and would massively simplify how I build my dotfiles.
I guess I should tell r/unixporn at some point, huh? (:
It sadly can't. Regex paths are hard due to the way it's implemented; if it was intercepting syscalls via ptrace then regex would be a lot more viable, but since this is just a glorified collection of bind mounts in the end, I'm unsure how I'd implement that nicely...
Okay understood. Consider adding a way to query all files written by a boxed application. If it generated a config file based on this info that would be super useful. Thanks for considering!
Maybe I've misunderstood, but it seems like this would only help for files the program puts in places itself. Thus it wouldn't help with files placed by the installer would it?
The biggest problem with getting programs to respect the XDG spec isn't getting programs to move their config file from $HOME/.myproj.yaml to $HOME/.config/myproj/config.yaml. It's getting projects not to store configuration and secrets in the same file.
So much for checking all of $HOME/.config into a Git repository.
Instead of chrooting to somewhere else, replicating your filesystem, ..., this switches into a new mount namespace and uses bind mounts to shadow the files/directories that are intended to be redirected. This way your entire filesystem continues to be visible to the target application, and only the paths you want altered are altered.
but... if you use unprivileged user namespaces, tmux isn't a very good use, because then you can't use any suid programs like su, sudo, doas, pkexec, fusermount, mount (user), etc.
This is pretty cool! It's surprising to see the project be at version 0.2.5 when the first commit was _yesterday_ though. What's the reason behind cutting this many releases?
I humbly submit either bash, sh, or zsh --- they all put dotfiles in $HOME that you can't move (zsh technically /can/, but they're still dotfiles and you have to set them in ~/.zshenv). Very annoying IMO.
Course, might not work so well with the way boxxy is run ... unless you chsh to boxxy bash or something.
i was using a similar bind-mount trick as Boxxy for a good 6 months or so, and then reworked it to prefer symlinks a couple months ago. nearly everything behaves as you’d expect with symlinks if you’re just symlinking within ~, and it’s easier to tell what’s going on or debug stuff.
notably, at some point i decided to encrypt my valuables: password store, PII, etc, and have them unlocked on login via PAM. i also wanted these to be locked when i lock my session. if you have, say, a ~/private mountpoint with sensitive stuff, and then ~/.password-store (for your password manager) pointing somewhere into this store, 2 things can happen when you `umount ~/private`
1. if ~/.password-store was a bind mount over ~/private/, your decrypted passwords will still be accessible through ~/.password-store.
2. if ~/.password-store was a symlink into ~/private/, then your passwords aren’t accessible.
chances are you wanted (2), and it might be scary when you discover that’s not what you had, months after setting it up…
i’ve also had some nasty mount duplication, where some cron job bind-mounts the same thing every hour. turns out linux will happily let you create identical bind mounts as many times as you want, until `/proc/mounts` has 2000 entries and some O(n^2) behavior somewhere in systemd’s namespace setup makes `systemctl start foo` take 3 minutes before invoking any service code. that was a PITA to figure out.
the worst thing that happens when you “mount” the same thing twice when using symlinks, on the other hand, is you get some very obvious nesting. so anyway, i’ve bit myself a few too many times. i’m very weary to reach for bind mounts anywhere symlinks can also do the job.
if you can make a /etc/fstab entry for your filesystem, then you can configure pam_mount using the same options as the fstab entry and it should work.
for the actual encrypted filestore, i’m using gocryptfs. it’s a more actively developed alternative to eCryptfs: mostly a drop-in replacement. there’s a lot of options here: dm-crypt over a dedicated partition is probably what a cryptographer would recommend, everything else is making tradeoffs (e.g. leaking metadata like file size/directory entry count) for better UX elsewhere. read the wiki to pick the best for your needs :)
on the off-chance you’re using NixOS, i configure these parts here:
Easy solution for that is what I do, just cd to the directory you want the symlink placed in, and then create it with one path instead of two. No need to think about whether or not the order is correct. It's really obnoxious that Windows chose the opposite syntax. (Yes. I have an unnecessary number of junction points and hard links on my system. When I reinstall next, I'll have a bad time dealing with it)
I wonder what the demographic for HN looks like. I never questioned how much younger the audience would be than me (and I definitely remember Boxxy and the related internet/4chan drama).
My current dotfiles [1] already have a lot of these and they mostly just work. Once in a while an application won't respect it completely, and so instead of having a mess with xdg + whatever the dev though was cooler I just let the application do it's thing so at least is somewhat predictable.
[0]: https://github.com/b3nj5m1n/xdg-ninja
[1]: https://github.com/DoodlesEpic/Dotfiles/blob/main/.profile