Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS dotfiles should not go in –/Library/Application Support

becca.ooo

Post reply on HN
Print view View original

201–210 of 223 posts

Re: macOS dotfiles should not go in –/Library/Application Support

#201

Post by smcleod »

delta_p_delta_x wrote: post #147
smcleod wrote: post #143

Earlier quoted context omitted.

I was responding to your comment about hidden (.) files vs extended attributes. As much as I do not like Android - it does respect hidden files. I don't 'bother releasing stuff for Windows', as I said - for me it's not worth the pain.

It's hard to tell how your commment was a sincere response rather than derision for anyone using or targeting Windows. There was nothing technical. Here's a technical response: There's nothing 'hidden' about dotfiles on UNIX-likes, unlike on Windows where, as I mentioned, there is such a thing that is exposed by the OS filesystem API (it's a normal attribute and can be straightforwardly set/unset with right-click ->…

It's standard convention for (mostly GUI) applications to visually hide files and directories that start with a ., I don't know what you think a hidden folder is if it's not this and it has been widely accepted in the industry as a whole (except in Windows) for a very long time.

What you seem to be confusing it with is file system ACLs, something that *nix for quite some time. In fact it was available on consumer desktop environments in the early 2000s - roughly the same era as Windows (when Microsoft brought their NTFS filesystem to the desktop).

Anyway, don't feed the trolls and all that, you're welcome to enjoy your windows ecosystem - just don't expect all engineers to write their software specifically to cater for it.

Re: macOS dotfiles should not go in –/Library/Application Support

#202

Post by OJFord »

joshka wrote: post #154
OJFord wrote: post #97

Earlier quoted context omitted.

> this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable. Why another one? If an XDG env var is set explicitly, that's obviously what the user wants. Just don't (necessarily) use the spec's defaults when it's not set.

The xdg vars only control the location. There’s no var to control that xdg should be used. macOS has a canonical approach, which some tools choose to ignore. I want a flag to make that ignorance correct

I know, but if XDG vars controlling the location exist then obviously 'use XDG' is desired.

Re: macOS dotfiles should not go in –/Library/Application Support

#203

Post by Izkata »

lucideer wrote: post #145
ndegruchy wrote: post #120

I disagree with this. macOS isn't Linux, and as much as I _absolutely support_ the XDG BaseDir spec, I don't think it's fair to try and apply it to macOS. Linux has no 'proper' directory for storing configuration, cache and application user data. macOS and Windows _do_. It's only proper to support those systems in the way that they intend. I wouldn't put stuff in to `%HOME%\.config` on Windows any more than I would p…

> Why would macOS get bundled in with Linux? Because it's a unix? That's silly. I'm somewhat on the fence about this topic in general & I think you've hit upon why. This isn't silly. At all. Linux & Mac environments are by no means compatible but for anyone who cares about the location of their dotfiles, the two systems have demonstrably been "compatible enough". To the point that having coordinated standards on some…

> Though the flip side of my own subjective take here is that "home directory dotfile vomit" has just never seemed as big an issue to me as many make out.

When I first switched from Windows to Ubuntu, I considered it an amazing feature for discoverability, especially since there was a pretty reliable pattern of using the executable's name for the dotfile/dir.

Re: macOS dotfiles should not go in –/Library/Application Support

#204

Post by ack_complete »

kbolino wrote: post #173
delta_p_delta_x wrote: post #125

Earlier quoted context omitted.

> I wouldn't put stuff in to `%HOME%\.config` on Windows Haha, and yet so many (usually Linux-first) applications do. Here's `gci $env:USERPROFILE -Force` on my computer: d---- 3/6/2022 04:39 .android d---- 6/9/2024 18:14 .cache d---- 31/7/2025 11:10 .claude d---- 16/8/2024 01:38 .config d---- 2/3/2022 07:25 .dlv d---- 7/8/2025 18:20 .dotnet d---- 19/7/2022 07:15 .eclipse d---- 1/4/2022 16:29 .fop d---- 12/10/2024 23…

On the other end, when Windows first started having multiple users and locking down write access to system directories (*), lots of video games (and some other programs besides) decided to just dump their files anywhere. Just looking at my own system, I see all of the following used: %userprofile%\Documents (which used to be called "My Documents") %userprofile%\Documents\My Games %userprofile%\Documents\Saved Games %…

Unfortunately, there is a reason. During the Vista timeframe, Microsoft published guidance recommending that game developers use the Documents folder for save games, as part of the push to make games compatible with UAC and non-elevated user accounts.

https://learn.microsoft.com/en-us/windows/win32/dxtecharts/g...

> What this means is that you should not place save games in \Program Files, instead they should go in a sub-folder in \My Documents.

Re: macOS dotfiles should not go in –/Library/Application Support

#205

Post by delta_p_delta_x »

smcleod wrote: post #201
delta_p_delta_x wrote: post #147

Earlier quoted context omitted.

It's hard to tell how your commment was a sincere response rather than derision for anyone using or targeting Windows. There was nothing technical. Here's a technical response: There's nothing 'hidden' about dotfiles on UNIX-likes, unlike on Windows where, as I mentioned, there is such a thing that is exposed by the OS filesystem API (it's a normal attribute and can be straightforwardly set/unset with right-click ->…

It's standard convention for (mostly GUI) applications to visually hide files and directories that start with a ., I don't know what you think a hidden folder is if it's not this and it has been widely accepted in the industry as a whole (except in Windows) for a very long time. What you seem to be confusing it with is file system ACLs, something that *nix for quite some time. In fact it was available on consumer des…

I am confused. My point was that if engineers target Windows at all, they ought to do it properly, but you retorted with 'I don't target Windows'. Okay, well and good, then my advice isn't for you and developers like you.

Then again, you said 'don't expect all engineers to write their software specifically to cater for it', seemingly ignoring my and essentially every parent commenter's plea for developers targeting non-Linux platforms to be good citizens on that platform, and adopt platform conventions. If you're not writing software for Windows, then sure, no need to think about Windows. If you are, or you are going to, then this platform convention business needs to happen and needs to be done correctly, whatever your thoughts on Windows, or, in the thread's case, macOS, where application data should go in `~/Library/Application\ Support` and not dot-dirs in $HOME.

The conversation digressed into cherry-picking my explanation of 'hidden file'. I'm not sure the troll epithet is fair.

Re: macOS dotfiles should not go in –/Library/Application Support

#206

Post by varenc »

OJFord wrote: post #95
varenc wrote: post #62

Earlier quoted context omitted.

Agreed! but mostly moot. As a general rule, CLI utilities which are just single binaries should not go in /Applications. That folder is for app bundles which are folders with a .app extension, an Info.plist file, etc. And its not on the PATH used in the shell (by default). I think the exception is app bundles which also include some sort of auxiliary CLI utility that usually gets symlinked from its location in the /A…

It's not moot though, because this whole thing is about the CLI binaries (usually because of a decision made by a framework like dirs-rs) using 'Application Support' et al.

I meant to say that 'If your binary is supposed to live in `/Applications`, by all means put its config in `~/Application Support`' is moot because CLI binaries aren't in /Applications ever

Re: macOS dotfiles should not go in –/Library/Application Support

#207

Post by CGamesPlay »

adastra22 wrote: post #168
CGamesPlay wrote: post #7

Earlier quoted context omitted.

I think there should be two crates in rust-land. The answer by @soc makes sense for apps , as the article discusses. Many (most?) people building Rust programs aren't making apps and so shouldn't be using this crate, which clearly and definitively only supports MacOS "Apps".

A CLI app is an app.

Not in Apple's nomenclature, it isn't. An App specifically refers to a folder named ".app" with an info.plist and a binary inside of it. It can also contain a bunch of other metadata and application data. To apple, a "CLI app" as you call it is just the binary (a single file).

But the real distinction is that the "Apple App" manages its preferences in-app. The "CLI app" does not, the user is expected to manage this configuration themselves.

Re: macOS dotfiles should not go in –/Library/Application Support

#208

Post by adastra22 »

CGamesPlay wrote: post #207
adastra22 wrote: post #168

Earlier quoted context omitted.

A CLI app is an app.

Not in Apple's nomenclature, it isn't. An App specifically refers to a folder named ".app" with an info.plist and a binary inside of it. It can also contain a bunch of other metadata and application data. To apple, a "CLI app" as you call it is just the binary (a single file). But the real distinction is that the "Apple App" manages its preferences in-app. The "CLI app" does not, the user is expected to manage this c…

What you are talking about is an application bundle.

Re: macOS dotfiles should not go in –/Library/Application Support

#209

Post by pdpi »

varenc wrote: post #206
OJFord wrote: post #95

Earlier quoted context omitted.

It's not moot though, because this whole thing is about the CLI binaries (usually because of a decision made by a framework like dirs-rs) using 'Application Support' et al.

I meant to say that ' If your binary is supposed to live in `/Applications`, by all means put its config in `~/Application Support` ' is moot because CLI binaries aren't in /Applications ever

That's what I was hinting at. MacOS is kind of split into two personalities, and the way to be a good citizen in the system is to respect the boundaries between those two personalities. CLI tools are definitely part of the Unix personality and should follow its conventions.

Re: macOS dotfiles should not go in –/Library/Application Support

#210

Post by pasc1878 »

chrisweekly wrote: post #108
pasc1878 wrote: post #67

Earlier quoted context omitted.

So set it to ~/Library/Preferences and no one should be complaining - Apple see configs in the correct place and XDG see it correct as well. So why is there a problem?

Apple's docs have this to say about ~/Library/Preferences/: This directory contains app-specific preference files. You should not create files in this directory yourself.

Provide the whole quote. Contains the user’s preferences. You should never create files in this directory yourself. To get or set preference values, you should always use the NSUserDefaults class or an equivalent system-provided interface.

The system provided interface in XDG apps is the XDG path - the Apple code there implies writiing a GUI app as none of the paths it says are not updated by the App ie no manual updates.

Post reply on HN