Creating a file if it doesn't already exist is idempotent.

You upgrade the software and it no longer works right. No one else reports the same issue. Turns out the version you tun for the very first time wrote a config in a location you never looked, and that config is incompatible with latest version.

Hidden files on MacOS were used sparingly—the main instance of a hidden file is the file which stores an icon for a folder, if the folder has a custom icon. Hidden files are only hidden from the UI, they appear normally in the command line.

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.

Personally, I think hidden files are OK, but we have lousy defaults, regardless of OS.

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.

When I run ls I don't want to see all the configuration files. Just my files. I think that's the point of hidden files.

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

>What's the point of hiding some of the files in a directory from user? It only makes things more confusing.

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.

Re accidental deletion, ntfs also has a "system" flag. Windows prompts if you delete one of those.

i just always list dotfiles for years now.. and my IDEs too. mostly a non issue.

The reason app developers think it's fine to dump them in $HOME is because Linux hides them. Those app developers do not bother hiding them on Windows. The specific functionality being used does not 'work just fine everywhere'. 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.

> Nobody should go out of their way to integrate with Windows APIs

  int writeConfigFile(ConfigFile file) {
  #if defined(_WIN32)
      // Windows-specific function
  #elif defined(__linux__)
      // Linux-specific function
  #elif defined(__APPLE__)
      // macOS-specific function

With modern C++, there's probably a way to do this in a nicer manner, and achieve runtime polymorphism with virtual functions or a lambda (function pointer) table.

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.

It’s basically the same as looking up $XDG_CONFIG_HOME on GNU/Linux.

I'm not sure I'd call that configured well. On Linux, share is supposed to contain static data used by the app, not the changing configuration that normally goes into appdata on Windows. For config the equivalent should be ~/.config/appname

Your argument breaks down even between 'Unixy' systems. Linux programs that follow the XDG base directory specification write to those, whereas macOS programs tend to write to ~/Library/Preferences or ~/Library/Application Support, neither of which exist on Linux, or even BSDs.

When in Rome, do as the Romans do.

> I prefer the app placing the config in the same place on every system.

That is impossible because in Linux there is no drive letters and you cannot have the same path to a file as in Windows.

The difference between Windows ".." and unixy ".." is that the former is done lexically whereas the latter is a link to the canonical parent.

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.

Hold your giggles until you learn that windows MAX_PATH is only 260 characters. Not just filename, the entire path.

Unless an app uses \\?\ prefixes and special API for navigation, which is rare, ime.

> on Windows

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 .NET, with `System.IO.Path.Combine(String, String)`.

In PowerShell and .NET, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.

It seems the only official native API for getting the parent directory from a known (full) path is PathCchRemoveFileSpec. But certainly C# and other similar platforms have functions doing similar things, and usually don't require a system API call anyway, it's just string manipulation - unless of course the path is relative to the current directory.

".." works fine in Windows environments.

One could say the same for ~ on Linux. 'It's already bad' isn't an excuse for sloppy programming.

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.

Hmm, that's why I said inherent? Because as you mentioned there is a separate macOS directory structure and the system utilities don't follow the specification. Also, the specification is only written for Linux in mind, which is why I said "not inherent for macOS.

Is there an exact phrasing you would prefer?

Using some long exa incantation risks alienating people that don't care about things like the latest trendy grep alternative

Exa is the latest, trendy ls alternative.

I don’t think you should remove the Exa example but you certainly should show how to use ls to do something similar for those people still living in the dark ages—ls was created in the 1970s and it hasn’t kept up with the times all that well [1].

I created an ‘ll’ alias for Exa using the Fish shell; obviously you make shell-appropriate aliases in Bash or Z shell:

    function ll
      exa --color always --long --no-user --no-permissions --all --icons $argv
    end

[1]: https://the.exa.website/introduction

Thanks for the suggestion - agreed, I'll make that change

no I think you're right, that was a typo

Mainly because it's easier to get people on board when we're keeping a few of the super core dotfiles, especially since those are kind of impossible to change - they are hard coded literally everywhere

Admittedly, the ~/.bashrc etc. files should be there too - but I wanted it to look cleaner :P

This sounds like “let’s design something nobody ever will use”. Compare how often you (or anyone) created, edited, deleted or backed up a ~/.dotfile vs some file who-tf-knows-where in AppData or Library mazes. These have near zero discoverability and expect-ability.

There are better alternatives

Let’s define “better” first.