This isn't just a Linux problem. In Windows, the users /documents folder is polluted in exactly the same way these days.
Then if you try to make a dotfile through powershell, it has a different text encoding than *nix, which some programs (git) rely on
It does, rename it .dotfile. so with an extra . at the end.
it has a different text encoding than nix,*
You don't specify how you do this, but most text output commands out there have an -Encoding parameter. Or else set it globally to what you want, good read here: https://stackoverflow.com/questions/40098771/changing-powers...
(I never used MacOS, but from the article it seems not the case for MacOS?)
It's a laziness issue, it won't be solved solely by making is easier to access the right locations on each system/platform, but that would be a step in the right direction.
Part of the problem in Windows is that Program Files is write protected for security, so you can't store a local configuration file relative to the exe. So where does it go?
I assume there must be documentation from Microsoft and Apple about best practices for this... I hope?
To answer your last question: in Qt you can use QSettings and it'll write to a canonical platform-specific location. Useful for storing eg the last accessed folder in a GUI, or things which users don't reallty need to change regularly.
This hasn't been a problem since the first version of Windows that had a filesystem with such protections - that would be Windows NT 3.1.
The correct location for such stuff is %USERPROFILE%\AppData\Roaming or ...\Local, depending on whether those settings are machine-specific, or should be synced across all devices for that user accounts (in environments where this is appropriate, such as domain networks). This particular location is in use since Vista - before, the names were slightly different ("Application Data"), but in any case a well-behaved app is supposed to use Win32 API to retrieve the correct path, rather than hard-coding it - which also worked on Win9x.
> I assume there must be documentation from Microsoft and Apple about best practices for this... I hope?
Of course.
https://docs.microsoft.com/en-us/windows/desktop/shell/known...
https://developer.apple.com/library/archive/documentation/Fi...
The problem is that so many apps just straight up ignore all those guidelines.
The fact it happens so often suggests that the documentation isn't good enough.
> Of course.
At least Apple's pages is pretty clear and has some nice diagrams.
I think this page is more appropriate: https://docs.microsoft.com/en-us/windows/desktop/shell/csidl
It's reasonably well documented for UWP, though I can't find an equivalent for Windows: https://docs.microsoft.com/en-us/windows/uwp/design/app-sett...
Hence why I suggested that Qt has the right approach. It also has http://doc.qt.io/qt-5/qstandardpaths.html which abstracts out standard paths for cross-platform applications.
Any library or framework author knows that documentation is never enough. ~ On Windows, though, there's also historical reasons - back in Win9x days, there was no practical reason for apps to bother if they didn't anticipate running on NT, which is why it was so common to just dump configs next to the .exe (and even to this day, Windows uses FS virtualization to make this work for old apps). When 2K and especially XP became popular, and everyone was rapidly porting their stuff, people often didn't bother looking up docs and all, and just used the "least significant change" approach to fixing things. And that kind of set the background for later - why bother being nice, if nobody else does?
> I think this page is more appropriate: https://docs.microsoft.com/en-us/windows/desktop/shell/csidl
This page describes pre-Vista, deprecated APIs. Unless you need to target XP, a desktop app should use the known folder mechanism.
Actually the current documentation refers you to the CSIDL list if you want to know what any of the GUIDs actually mean. The new docs just provide a list of IDs with minimal information.
See https://docs.microsoft.com/en-us/windows/desktop/shell/known...
Madness.
Hardcoding paths is a bad idea, since they can change - indeed, they have already changed once in Vista, and the paths that you suggest are obsolete on Vista and above - it's %UserProfile%\AppData now (although it still provides symlinks for compatibility).