4 ms·

I doubt anyone running Unix-style command-line/TUI tools where the config files are expected to be edited by hand by the user is expecting to find it in the App

by re 1y ago

I doubt anyone running Unix-style command-line/TUI tools where the config files are expected to be edited by hand by the user is expecting to find it in the Application Support directory; that directory is not a directory that Apple intends for users to ever interact with directly: > Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app uses to run but that should remain hidden from the user. [emphasis added]

JoshTriplett 1y ago
> where the config files are expected to be edited by hand by the user Many good command-line tools manage their config files automatically, in addition to allowing the user to hand-edit them. I don't think that materially changes this, though: people may still expect to find them in `~/.config`.
joshka 1y ago
(I maintain a fairly popular TUI library), and as a CLI/TUI user on macOS, I dislike the App Support folder a lot. But even though I dislike it, I'd expect that apps for mac should put their files there because the XDG spec doesn't apply to macOS. It's the wrong place, but the technically correct one. The right thing to do is fix the spec, and then fix the apps / libs to follow that. I wrote a top level thread that this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable.
- re 1y ago
  How does the XDG spec not apply to macOS, and what "fix" are you proposing? https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/ https://www.theregister.com/2024/10/11/macos_15_is_unix/ https://www.theregister.com/2024/10/11/macos_15_is_unix/ > Probably another environment variable Having any of the existing XDG_* environment variables set is an incredibly-clear indication that the user wants the XDG spec followed.
  - pjmlp 1y ago
    Because it was designed for Linux distros, by Linux distros, not UNIX vendors. Where is XDG on Open Group standards?
  - joshka 1y ago
    The XDG environment variables only apply to systems where the XDG spec is defined to be in place. You need one extra flag for defining that to be true. Given that macOS isn't a place where XDG is applicable, suddenly making it applicable would break every place that assumes that it's not applicable (e.g. I no longer have configuration for some utility that uses the pre-change value of the AppSupport folders.
- mbreese 1y ago
  And I’d also argue that the App Support folder doesn’t apply to CLI/TUI config files either. Apple doesn’t force CLI programs it distributes from storing files in App Support. If this were the case, wouldn’t you also expect the .ssh folder to be relocated from $HOME to App Support on a Mac? Much like the original author, my opinion is that you should do the least surprising to the user and if that’s not what the spec says, so be it.
  - GoblinSlayer 1y ago
    Maybe it's because it's not their programs and they want to pull from upstream?
    - mbreese 1y ago
      I completely expect for that to be the case. My point is, there are already programs distributed with macOS that don’t put config in the ~/Library/Application Support folder. Knowing this, I don’t see a good argument for (especially portable) CLI/TUI programs for keeping user editable config data in the App Support folder.
- OJFord 1y ago
  > 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.
  - joshka 1y ago
    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
    - OJFord 1y ago
      I know, but if XDG vars controlling the location exist then obviously 'use XDG' is desired.
      - joshka 1y ago
        No. There are many situations where these are set where that’s not true.
JdeBP 1y ago
Missing from the "hidden from the user" argument is the fact that .config, and dotfiles in general, are also hidden from the user. It's not the defining distinction that one may think it to be.
- re 1y ago
  Command-line binaries are also typically installed at locations hidden from the user (/bin, /opt/homebrew, ~/.bin, ~/.cargo/bin). Further indication that the "app"-oriented Apple documentation is intended only to apply to "apps", which are installed at /Applications or ~/Applications.
GoblinSlayer 1y ago
Hidden from the average Joe who will see these unknown files as garbage and delete them, cf Android.

by re 1y ago

JoshTriplett 1y ago

> where the config files are expected to be edited by hand by the user Many good command-line tools manage their config files automatically, in addition to allowing the user to hand-edit them. I don't think that materially changes this, though: people may still expect to find them in `~/.config`.

joshka 1y ago

(I maintain a fairly popular TUI library), and as a CLI/TUI user on macOS, I dislike the App Support folder a lot. But even though I dislike it, I'd expect that apps for mac should put their files there because the XDG spec doesn't apply to macOS. It's the wrong place, but the technically correct one. The right thing to do is fix the spec, and then fix the apps / libs to follow that. I wrote a top level thread that this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable.

re 1y ago
How does the XDG spec not apply to macOS, and what "fix" are you proposing? https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/ https://www.theregister.com/2024/10/11/macos_15_is_unix/ https://www.theregister.com/2024/10/11/macos_15_is_unix/ > Probably another environment variable Having any of the existing XDG_* environment variables set is an incredibly-clear indication that the user wants the XDG spec followed.
- pjmlp 1y ago
  Because it was designed for Linux distros, by Linux distros, not UNIX vendors. Where is XDG on Open Group standards?
- joshka 1y ago
  The XDG environment variables only apply to systems where the XDG spec is defined to be in place. You need one extra flag for defining that to be true. Given that macOS isn't a place where XDG is applicable, suddenly making it applicable would break every place that assumes that it's not applicable (e.g. I no longer have configuration for some utility that uses the pre-change value of the AppSupport folders.
mbreese 1y ago
And I’d also argue that the App Support folder doesn’t apply to CLI/TUI config files either. Apple doesn’t force CLI programs it distributes from storing files in App Support. If this were the case, wouldn’t you also expect the .ssh folder to be relocated from $HOME to App Support on a Mac? Much like the original author, my opinion is that you should do the least surprising to the user and if that’s not what the spec says, so be it.
- GoblinSlayer 1y ago
  Maybe it's because it's not their programs and they want to pull from upstream?
  - mbreese 1y ago
    I completely expect for that to be the case. My point is, there are already programs distributed with macOS that don’t put config in the ~/Library/Application Support folder. Knowing this, I don’t see a good argument for (especially portable) CLI/TUI programs for keeping user editable config data in the App Support folder.
OJFord 1y ago
> 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.
- joshka 1y ago
  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
  - OJFord 1y ago
    I know, but if XDG vars controlling the location exist then obviously 'use XDG' is desired.
    - joshka 1y ago
      No. There are many situations where these are set where that’s not true.

JdeBP 1y ago

Missing from the "hidden from the user" argument is the fact that .config, and dotfiles in general, are also hidden from the user. It's not the defining distinction that one may think it to be.

re 1y ago
Command-line binaries are also typically installed at locations hidden from the user (/bin, /opt/homebrew, ~/.bin, ~/.cargo/bin). Further indication that the "app"-oriented Apple documentation is intended only to apply to "apps", which are installed at /Applications or ~/Applications.

GoblinSlayer 1y ago

Hidden from the average Joe who will see these unknown files as garbage and delete them, cf Android.