Live data from Hacker News

Show HN: boxxy – Control where Linux programs put files, without symlinks

github.com

181–190 of 250 posts

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#181

Earlier quoted context omitted.

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 does (did at least) And macOS has Xxx.localized directories

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.

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#183

Earlier quoted context omitted.

> 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 con…

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 u…

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.

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#184

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…

Does it use a centralized database of all known software?

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#185
post #94

Earlier quoted context omitted.

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…

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…

> 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.

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#186

Earlier quoted context omitted.

> some have hardcoded those paths in other scripts My sympathy is lacking, as is my respect for those running projects that hardcode paths. Stop hardcoding paths and the world will be a better place.

eg. ~./bashrc has existed there for 30+ years, changing stuff just because someone doesn't like seeing a file in a folder is imho stupid.

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.

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#187
post #168

This is neat! What's so bad about symlinks though?

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.

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#188

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…

Does it use a centralized database of all known software?

The information comes from Arch Wiki's list of everything known [0].

[0] https://wiki.archlinux.org/title/XDG_Base_Directory

Re: Show HN: boxxy – Control where Linux programs put files, without symlinks

#189

Earlier quoted context omitted.

Windows does (did at least) And macOS has Xxx.localized directories

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.

I 100% agree. Localized directories was a stupid mistake. The way Windows does it today is much better and XDG should follow suit.
Post reply on HN