There are many ways to access the filesystem on Windows. CMD.exe and PowerShell respect `..` to go to the parent directory, as does MSVC C++17 with `std::filesystem`, and C#, with `System.IO.Path.Combine(String, String)`.
In PowerShell and C#, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.
At least in case of std::filesystem, everything in std::filesystem::path is purely lexical. So, to get actual parent of some path, you'll need to go through std::filesystem::directory_entry and std::filesystem::read_symlink().
--
E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory.
That said, Unix shells can muddy the waters a bit. They may choose to act lexically with some commands.
Worth noting here that Plan 9 is using lexical names[1], and the Go standard library offers the function path.Clean[2] to achieve similar results. If your language/library/OS doesn't offer this behavior by default, it's likely a good idea to add/reimplement this function, unless you need bug-for-bug compatibility.
[1]: https://web.archive.org/web/20220824070659/https://9p.io/sys...
Unless an app uses \\?\ prefixes and special API for navigation, which is rare, ime.
Environment.GetFolderPath( SpecialFolder.LocalApplicationData)
~/AppData/Local
~/.local/share
Software should ideally adhere to OS norms. Better still, software shouldn't be opaque about where global/user-specific cache/config data is stored, and should prompt users to choose (or set sane defaults, again adhering to OS norms).
IMO the video game industry is a big offender of home-folder pollution, with saves and configs being splattered all over %USERPROFILE%\Documents, %USERPROFILE%\My Documents\ (which is a legacy holdover from Windows XP), %USERPROFILE%\Saved Games (which does have a corresponding KNOWNFOLDERID), etc etc.
Right now the offenders in my $HOME not following $XDG are games, LibreWolf ala Mozilla, and anything related to npm (with their maintainers closing any issued opened about support $XDG).
I recognize this is probably because I first learned about config files on a Unixy system, it's not the "native way" for Windows, and other people have stronger cases for their preference, but this is my preference and I'm stickin to it :)
When in Rome, do as the Romans do.
Yeah, but then again, when you visit Rome for a short vacation as a tourist, the English versions of menus and such help, no?
Just saying, some degree of consideration for non-natives is a good thing, as it will help the tourism business generate more revenue. Same for OSes: give me at least an option of staying with my old habits until I get used to the new ones, then there's a higher chance I'll switch.
That is impossible because in Linux there is no drive letters and you cannot have the same path to a file as in Windows.
People aren't obligated to "comply" with the XDG specification either. It's not a bug to just use $HOME.
There is a difference between being cross-platform, and being Linux but mangling it so it technically works on other platforms.
https://stackoverflow.com/a/42700844/512904
> being Linux but mangling it so it technically works on other platforms
Sounds like the easiest way to solve this problem. I don't blame or shame developers for choosing it.
This is simple and works everywhere:
char * home = getenv("USERPROFILE");
if (home) {
// Use home directory
}
WCHAR profilePath[MAX_PATH];
HRESULT result = SHGetFolderPathW(NULL, CSIDL_PROFILE, NULL, 0, profilePath);
if (SUCCEEDED(result)) {
// Use home directory
}
Just because you aren't used to it doesn't mean it's 'bullshit'. Might I provide a counterexample to the 'simplicity' of Linux? Developing video games natively on Linux is such a pain point that the industry has standardised around simply translating Windows syscalls and Direct3D shaders to their Linux equivalents, because the latter is so heavily fragmented to develop natively for. Also known as Proton.
Honestly I don't even disagree with you. I think POSIX sucks. I think even the libc sucks. However there is no way you can look at the Windows API mess above and think it's somehow better than the portable and clean getenv function call. Maybe you can "get used" to that cruft but I can't. If I had to deal with code like that the first thing I'd do is abstract it away so I don't have to deal with it anymore. That's exactly how Windows is and should be treated by everyone.
Video games, your counter example, are probably the most platform-specific software imaginable. There's a reason pretty much everybody uses an engine these days. There is no way you can compare that stuff to getting a user's home directory and writing files in there.
Also, for video games it ultimately doesn't matter how sucky the APIs are since it's all about market share anyway and people will use whatever they need to get it done. First parties don't put in effort into porting games to Linux because they don't see the money. Valve puts in effort because it gives them their own platform that they control and therefore leverage over Microsoft and its app store. Emulation and compatibility layers are a proven solution when first parties aren't playing ball. If they don't want to make it work on Linux, people will make it work whether they want it or not.
Also, you're comparing something it makes zero sense to compare. People are not saying 'you need to fetch $USERPROFILE without calling getenv'. People are saying 'you need to not store random garbage in $USERPROFILE'. Calling getenv("APPDATA") is a perfectly fine way of fetching FOLDERID_RoamingAppData, the same way you weren't going to bother calling getpwuid if $HOME was undefined.
It's just some example code. Real code will probably try a number of variables.
> Calling getenv("APPDATA") is a perfectly fine way of fetching FOLDERID_RoamingAppData
Okay then. Top level post said you needed a Win32 function for this. If you can do that without those functions, I suppose it's easy enough to support.
> calling getpwuid if $HOME was undefined
$HOME is set by login and ssh to whatever is in the passwd database. Can it ever be undefined? Seems like something is seriously wrong if it is.
int writeConfigFile(ConfigFile file) {
#if defined(_WIN32)
// Windows-specific function
#elif defined(__linux__)
// Linux-specific function
#elif defined(__APPLE__)
// macOS-specific function
As another sibling commenter wrote, .NET already has a platform-agnostic function to write to a `user program data` folder that nicely maps to the platform-specific directories. Other GC languages (Java, Go, etc) likely have similar abstractions.
As for scripting... A cross-platform project with scripts that also targets Windows should (in my opinion) have PowerShell `.ps1` scripts accompanying any `.sh` scripts. Better still, scripting should be done in a language that's truly platform-agnostic, like Python.
You proved my point. Creating an #ifdef mess with polymorphism, virtual methods and indirection is the very definition of going out of one's way to support something that really doesn't need any support.
This is just part of the cost of developing cross-platform, and I'm sorry, but to me, dismissing this as 'going out of one's way' is just being sloppy.
I felt a great disturbance in the source, as if hundreds of BSD users suddenly cried out in terror and were suddenly silenced.
I initially did think of simply letting the build system handle it (CMake can do this excellently, as can Meson, probably) by simply choosing different source files for different target OSs, but when typing out the parent comment, I forgot about it in my train of thought.
Come to think of it, this is far more elegant.
Linux doesn't hide anything. It's POSIX and GNU tools that choose not show anything that starts with a dot by default. As far as Linux is concerned they're just normal files on the file system.
It doesn't have to be that way. Personally I have my system configured so that all "hidden" files are shown because I hate the concept of hidden anything. I used to do this in Windows too.
> The specific functionality being used does not 'work just fine everywhere'.
It kind of does. "Program reads configuration from a file" seems like a really basic thing that every operating system supports. There really is no need to directly depend on any Windows API stuff. Even worse would be suggesting the use of the registry.
> It is not the case that Linux functionality is How Computing Works with every deviation being 'out of the way', not even in a hypothetical world where Linux isn't the drastic minority of machines by an order of magnitude.
And yet Windows is the system getting "half-baked ports of Unix-first software" here. Why should the developers be shamed for not going of their way to support Windows conventions for Unix software?
I would actually argue otherwise: the registry is the perfect place to put configuration data, provided Microsoft's guidelines[0] on registry key creation/deletion and hive use are followed. I would argue every OS should have its own 'registry' for a universal location to set configuration for programs.
On the other hand, if every application has its own configuration file, then every application shall have its own configuration file parsing/serialising/deserialising routine. It's also what has led to this explosion of 'config file formats': .json, .yaml, .ini, .conf, .cfg, .toml, .xml.
I guess this is why people dislike systemd so much: it reminds them too much of Windows.
[0]: https://learn.microsoft.com/en-us/windows/win32/sysinfo/regi...
You appear to have an attitude of UNIX/Linux > Windows, which is unfortunate. The two OS families are different, but I personally believe neither is superior to the other. Both OSs suck in their own ways, both OSs are better in their own ways (this conclusion after using Windows and Linux both on a 70:30 time ratio).
Windows is in every way as modern an OS as Linux is, but just like Linux, has inherited strange baggage from its 40-year-old past, like 'a file cannot have COM in its name'.
Few people follow that stuff. I wouldn't be surprised if Microsoft's own people didn't follow that stuff. The result is of course a mess that users have to clean up with software like CCleaner or whatever people use these days.
It sucks even if those guidelines are followed. Configuration is data and belongs to the users. I know people who really like portable applications that they can keep on a USB drive and use anywhere and this registry bullshit breaks that.
> I would argue every OS should have its own 'registry' for a universal location to set configuration for programs.
And I would argue otherwise. The Windows registry is essentially a poor excuse for a proper file system. I think at least one Linux desktop environment tried to reinvent this crap and it sucked just as hard.
> every application shall have its own configuration file parsing/serialising/deserialising routine
The Windows registry values are essentially memory dumps of C types. It's perfectly possible to simply dump raw bytes into binary files on Linux too if you don't care about stuff like endianness. The result would be strictly superior to the Windows registry because the files are being stored in a real file system.
> I guess this is why people dislike systemd so much: it reminds them too much of Windows.
I like systemd.
Windows is the system everyone actually uses - even developers!. I write software because I care about people using it.
> Why should the developers be shamed for not going of their way to support Windows conventions for Unix software?
Because it's wrong on Unix, and even wrong on Linux, and once you are doing the right thing on Linux it is no longer out of your way.
Btw, many native, no-linux windows apps, including Microsoft ones love to create their bs folders like “My Games”, “Microsoft Visual Studio (c)(tm) <yearname> Pile of Whatever” or “Android Projects” right in ~/Documents. This “way” is unenforceable even in OS’es own company.
For example the folder might look empty but in fact it could contain thousands of hidden files. You want to delete it as it is empty but accidentally delete important system files.
Even worse, imagine if all files on an USB drive are marked as hidden. You see that the drive is empty but when you attempt to copy something to it see a message that there is no free space.
One more example. Imagine if you have a project and want to edit an .env file. But as dotfiles are hidden in Linux you don't see this file and cannot open it. It turns out that Windows Explorer which doesn't hide dotfiles is much better for developing projects with Docker!
There should be no hidden files. We cannot do anything with Windows and their MS-DOS legacy but Linux could stop hiding dotfiles in GUI and CLI commands.
The standard Unix folders (usr, var, etc) are also hidden—to be honest, this is a compromise because the Unix filesystem hierarchy sucks, but we are saddled with it for backwards compatibility reasons.
I did appreciate the relative clarity of old macOS systems—everything in the OS was in “System Folder”, the rest of the filesystem was yours, and you could freely move applications without breaking anything, uninstall them by putting them in the trash, etc.
There is no need to hide such files. Just display them as system files in Explorer.
> The standard Unix folders (usr, var, etc) are also hidden
Again there is no need to do it. Just move them to a directory named "System files".
Thumbnail caches are not stored on USB drives, they’re stored somewhere else, away from your files.
By the way, I'm pondering setting my XDG_*_HOME vars on Linux/BSD to use the macOS paths like ~/Library, just to see if the standard is actually being followed.
If a user doesn't know what .ssh/ or .bash_history are, and it can hurt them to accidentally delete or modify them, why show them by default? It's like training wheels on a bike.
>For example the folder might look empty but in fact it could contain thousands of hidden files. You want to delete it as it is empty but accidentally delete important system files.
If it is possible for a regular user to accidentally brick a system like this, it was doomed to begin with. If a user doesn't know what a dotfile is they shouldn't have administrative privileges, and if they do get them there is no safeguard to stop them destroying the system. It's not a dotfile issue.
>Imagine if you have a project and want to edit an .env file. But as dotfiles are hidden in Linux you don't see this file and cannot open it. It turns out that Windows Explorer which doesn't hide dotfiles is much better for developing projects with Docker!
In what reality is someone developing software and building Docker containers who doesn't understand the concept of hidden files? Seems awfully contrived.
This is really the problem with the home directory. It’s supposed to be the place where the user puts their files, but it’s also a place where applications put their files, usually without asking the user.
The battle is lost - the home directory territory should be ceded to applications and the user should have a separate space in which to manage their files.
This can sort of be achieved with the $XDG_CONFIG_HOME environment variable, but not all software respects it, so in practical terms it’s a lot easier just to leave $HOME to be the application config dumping ground.
Because they are there. To prevent accidental deletion you can show an icon with a skull and crossbones or name a directory "configuration files" so that it is obvious what's in there.
> if they do get them there is no safeguard to stop them destroying the system
If the folder are named or labeled as "operating system" then the user will probably understand that it is better not to mess with it.
> In what reality is someone developing software and building Docker containers who doesn't understand the concept of hidden files?
Hiding hidden files is annoying because you have to add -a to ls command, have to add an option in Bash to include then when matching against a star pattern and to configure Explorer so that it shows them. It would be easier without them.
This will make users more likely to delete it thinking it's a virus.
> If the folder are named or labeled as "operating system" then the user will probably understand that it is better not to mess with it.
Big assumption that most people know what an operating system is.
Have you ever heard of aliases?
You have permissions to prevent from accidental deletions.
By default, Explorer hides hidden files (and goes one step further and doesn't display file extensions: why???), so do Finder, Dolphin, Nautilus, and even `ls` by default.
file extensions are the mistake here really not them being hidden.
> One more example. Imagine if you have a project and want to edit an .env file. But as dotfiles are hidden in Linux you don't see this file and cannot open it.
How likely is it that someone is going to want to edit a .env file and not know how to view hidden files?
Well then configuration files can simply not be in the same directory as your files. Easy fix.
But they don't need to be hidden by being special, they can just be "hidden" by living in a subdirectory that you don't look inside.
Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths.
Windows also doesn't know what the dot at the beginning of a file/folder means. Instead, it and NTFS have something that's arguably better: a hidden file attribute `FILE_ATTRIBUTE_HIDDEN`[2], that's again settable/gettable when a file/directory is created or polled, rather than regex-ing for a full-stop.
The worst irony is Microsoft software creating dot-files and dot-dirs on Windows[3][4][5].
[0]: https://learn.microsoft.com/en-us/windows/win32/api/shlobj_c...
[1]: https://learn.microsoft.com/en-us/windows/win32/shell/knownf...
[2]: https://learn.microsoft.com/en-gb/windows/win32/api/fileapi/...
[3]: https://github.com/dotnet/sdk/issues/8678
[4]: https://github.com/OmniSharp/omnisharp-roslyn/issues/953
[5]: https://github.com/microsoft/vscode/issues/3884