5 ms·

Staff dev on 1Password’s developer tools here. We screwed this up in our first few releases of the 1Password CLI, largely out of ignorance. Those releases store

Staff dev on 1Password’s developer tools here. We screwed this up in our first few releases of the 1Password CLI, largely out of ignorance. Those releases stored config in $HOME/.op at first. But early feedback pointed us to XDG, so we migrated. Now we check: 1. $XDG_CONFIG_HOME/.op (if var is set) 2. $HOME/.config/op 3. $HOME/.op I hate to be the dev who says “I don’t know why those other code bases find it so difficult that they put up a fight” but our `findConfigDirectory()` function isn’t exactly complicated, even when you consider all the operating systems that the 1Password CLI supports. (Sorry for the formatting, I’m on my phone.)

halostatue 3y ago
And yet you impose XDG (originally a GNOME specification) on macOS (completely unrelated to GNOME or Linux). On macOS, you should be looking in ~/Library/Application\ Support/op and ~/Library/Preferences/op/config. I’ve got a script that I’m making conform to XDG, and it's a lot of work to make it work well because I have to know about three different roots for different things (configuration, temporary files, and persistent files). I’m not convinced that it's worth it, because it is no longer as easy as telling someone "uninstall this by doing `rm -rf ~/.PROGRAM`", but instead I have to say `PROGRAM self destruct` or something like that to clean up all the detritus (and what if it fails in the middle?).
- JoBrad 3y ago
  Sounds like they have a single place to fix it, though, which is nice.
  - halostatue 3y ago
    Yes. I think that the plugins should probably not be in $XDG_CONFIG_HOME, but in $XDG_DATA_HOME, if I’m reading correctly. But in part my point is that there's virtually no one who gets this correct either with Linux systems or macOS, which is what makes rants like the parent article so annoying.
    - account42 3y ago
      Plenty of programs get $XDG_CONFIG_HOME and $XDG_DATA_HOME. The ones that don't are mainly lazy ports from Windows where that speration doesn't exist.
- maleldil 3y ago
  As macOS user, I'd rather they use XDG than the "standard" macOS directories. Maybe there's a point to be made to use the standard if the XDG variables aren't set, but I'd generally avoid that for CLI apps. Having everything under ~/.config is more convenient.
  - b0afc375b5 3y ago
    Agreed. "Application\ Support" looks subjectively disgusting to me. It's the only path on my configuration with spaces. I have to use it because that's where vscode settings.json is placed.
    - moe 3y ago
      Rest assured this is not subjective. It is objectively disgusting.
    - easton 3y ago
      If it helps, it may have been for a good reason. Microsoft used to name the folder that stored user directories "Documents and Settings" so developers would be forced to make sure they could handle paths with spaces in them. Now, they call that folder "Users", and I had to make sure when I set up my Windows install that my name didn't have spaces in it so a bunch of apps didn't get screwy.
  - fjfuvucucuc 3y ago
    Xdg isnt just config. Using .config (xdg config) on Mac is super weird. Xdg is also, .cache (xdg cache dir) for data that can be cleared on reboot allowing you to use tempfs for it (of course you can't because a bunch of shit uses it as a persistent cache for things they should be putting in .local/share/. (Xdg data dir). This whole mess is so utterly fucked I gave up caring and just let the mess be.
    - maleldil 3y ago
      > Using .config (xdg config) on Mac is super weird. Why? Using it makes macOS more similar to Linux, which I think is a good thing. It surely makes it easier to share configuration files between Macs and Linux machines. Honestly, I don't see a single upside to using macOS's specific directories over .config/.cache/.local.
- eternityforest 3y ago
  Most prsistent files should never be cleaned on uninstall, you don't know why they're uninstalling, it could just be a reinstall to fix something. Configuration might not need cleanup either. Temporary files often shouldn't exist. If it's less that a few megabytes why is it touching disk unless it will be needed persistently? In any case the detritus doesn't matter, if it's big enough to care I'll see the disk space is low and find it with baobab at some point. It's not perfect, but it's not a major nightmare. For my part, I don't always follow XDG specs, I often just create ~/AppName, but sometimes I'll make more than one to keep features within one app separate. I put IP cam recordings in ~/NVR by default, and stuff like that, because the main app dir is all stuff you would backup and restore, which probably doesn't include NVR recordings for a home user.
  - deleted 3y ago
    [deleted]
- seanhunter 3y ago
  I'm pretty sure the XDG base directory spec was not specifically a gnome thing. It came from freedesktop.org[1] if I remember correctly, and in fact gnome was not compliant to begin with[2]. That gnome wiki page references that the recommendation (which turned into the spec) came from freedesktop and documents the gnome "initiative" to become compliant. Freedesktop was focussed on compatibility between desktop environments and systems, so isn't just a linux thing. [1] https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/ [2] https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/XDGConfigFolders?action=show&redirect=GnomeGoals%2FXDGConfigFolders https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/XD...
  - deleted 3y ago
    [deleted]
  - halostatue 3y ago
    Thank you for the information.
- RamblingCTO 3y ago
  And who's using that? You'd break user expectations with that. Sometimes it's not about being most correct.
  - halostatue 3y ago
    Yet…that is exactly the argument of the original post. The banner argument is that VIM is wrong because it doesn’t use `~/.config/vim` and instead uses `~/.vim` … which it has used since before XDG was created. Vim also doesn’t use ~/.vim` on Windows (and the files aren't `.vimrc` and `.gvimrc`, but `_vimrc` and `_gvimrc`. User expectations differ. The correct place to put application detritus is `~/Library` on macOS (`/Library` if it’s system-level with no user-level). I am surprised when a cross-platform library uses `~/Library` instead of XDG, but I am not unhappy with it. Frankly, most programs should have a command like `show-config-paths` (`--show-config-paths`) so that you can see where the configuration, caches, etc. are on the platform you’re on, and possibly be told (a) whether they are overridden from default and (b) how to override them. It would be useful to have that output for both human and machine reading.
    - IggleSniggle 3y ago
      I agree 100% on having a command to this effect. I always make sure that there is a command to show the currently resolved configuration location, as well as printing out configuration (minus secrets) when the application starts in debug mode. Furthermore, when you do '--help', whenever it's half-way reasonable, I will show you what your currently resolved settings are for any flags/variables/configs next to the corresponding flag, as well as the default value. I actually don't know why this isn't common.
- ClikeX 3y ago
  Has a MacOS dev, I'd prefer config like this in my home directory so I can easily access it between MacOS and Linux. My expectation for CLI tools is that config is in $HOME/.config/.
  - josephd79 3y ago
    I agree, as of right now all my CLI tools are in $HOME/.config. Do you have some that are not?
- saagarjha 3y ago
  ~/Library/Application Support is typically used for GUI applications. Using XDG seems reasonable for CLI tools?
exceptione 3y ago
Congratulations, you are in the top 10% for being a professional developer, correcting mistakes and not coming up with shitty excuses. If people from this thread took notice we all could have a clean $HOME and there would be no need for this non-discussion. As you found out, it is incredibly easy to conform to the spec.
- rascul 3y ago
  I had a clean $HOME before XDG came around. Now it's a mess.
  - wink 3y ago
    That makes no sense. You should at most have a single directory `~/.config` more and I suppose 90% of the tools writing or reading there could be configured to use ~/.${TOOL}rc
    - SAI_Peregrinus 3y ago
      XDG didn't (IMO) make things worse, but it also didn't help as much as it should have. My `~/.config` is the largest subdirectory of `~`, because every Chromium/Electron-based application uses `${XDG_CONFIG_HOME}/$APP_NAME/Service Worker/CacheStorage` and `${XDG_CONFIG_HOME}/$APP_NAME/Cache` (and a few other cache directories) instead of sticking those in `${XDG_CACHE_HOME}/$APP_NAME`.
      - exceptione 3y ago
        Have you filed a bug report?
        deviantintegral 3y ago
        Open since 2016! https://github.com/electron/electron/issues/8124 https://github.com/electron/electron/issues/8124
buttercraft 3y ago
Any particular reason for the cryptic, two letter file name instead of something descriptive?
- halostatue 3y ago
  op -> [o]ne [p]assword. It matches the command name.

halostatue 3y ago

And yet you impose XDG (originally a GNOME specification) on macOS (completely unrelated to GNOME or Linux). On macOS, you should be looking in ~/Library/Application\ Support/op and ~/Library/Preferences/op/config. I’ve got a script that I’m making conform to XDG, and it's a lot of work to make it work well because I have to know about three different roots for different things (configuration, temporary files, and persistent files). I’m not convinced that it's worth it, because it is no longer as easy as telling someone "uninstall this by doing `rm -rf ~/.PROGRAM`", but instead I have to say `PROGRAM self destruct` or something like that to clean up all the detritus (and what if it fails in the middle?).

JoBrad 3y ago
Sounds like they have a single place to fix it, though, which is nice.
- halostatue 3y ago
  Yes. I think that the plugins should probably not be in $XDG_CONFIG_HOME, but in $XDG_DATA_HOME, if I’m reading correctly. But in part my point is that there's virtually no one who gets this correct either with Linux systems or macOS, which is what makes rants like the parent article so annoying.
  - account42 3y ago
    Plenty of programs get $XDG_CONFIG_HOME and $XDG_DATA_HOME. The ones that don't are mainly lazy ports from Windows where that speration doesn't exist.
maleldil 3y ago
As macOS user, I'd rather they use XDG than the "standard" macOS directories. Maybe there's a point to be made to use the standard if the XDG variables aren't set, but I'd generally avoid that for CLI apps. Having everything under ~/.config is more convenient.
- b0afc375b5 3y ago
  Agreed. "Application\ Support" looks subjectively disgusting to me. It's the only path on my configuration with spaces. I have to use it because that's where vscode settings.json is placed.
  - moe 3y ago
    Rest assured this is not subjective. It is objectively disgusting.
  - easton 3y ago
    If it helps, it may have been for a good reason. Microsoft used to name the folder that stored user directories "Documents and Settings" so developers would be forced to make sure they could handle paths with spaces in them. Now, they call that folder "Users", and I had to make sure when I set up my Windows install that my name didn't have spaces in it so a bunch of apps didn't get screwy.
- fjfuvucucuc 3y ago
  Xdg isnt just config. Using .config (xdg config) on Mac is super weird. Xdg is also, .cache (xdg cache dir) for data that can be cleared on reboot allowing you to use tempfs for it (of course you can't because a bunch of shit uses it as a persistent cache for things they should be putting in .local/share/. (Xdg data dir). This whole mess is so utterly fucked I gave up caring and just let the mess be.
  - maleldil 3y ago
    > Using .config (xdg config) on Mac is super weird. Why? Using it makes macOS more similar to Linux, which I think is a good thing. It surely makes it easier to share configuration files between Macs and Linux machines. Honestly, I don't see a single upside to using macOS's specific directories over .config/.cache/.local.
eternityforest 3y ago
Most prsistent files should never be cleaned on uninstall, you don't know why they're uninstalling, it could just be a reinstall to fix something. Configuration might not need cleanup either. Temporary files often shouldn't exist. If it's less that a few megabytes why is it touching disk unless it will be needed persistently? In any case the detritus doesn't matter, if it's big enough to care I'll see the disk space is low and find it with baobab at some point. It's not perfect, but it's not a major nightmare. For my part, I don't always follow XDG specs, I often just create ~/AppName, but sometimes I'll make more than one to keep features within one app separate. I put IP cam recordings in ~/NVR by default, and stuff like that, because the main app dir is all stuff you would backup and restore, which probably doesn't include NVR recordings for a home user.
- deleted 3y ago
  [deleted]
seanhunter 3y ago
I'm pretty sure the XDG base directory spec was not specifically a gnome thing. It came from freedesktop.org[1] if I remember correctly, and in fact gnome was not compliant to begin with[2]. That gnome wiki page references that the recommendation (which turned into the spec) came from freedesktop and documents the gnome "initiative" to become compliant. Freedesktop was focussed on compatibility between desktop environments and systems, so isn't just a linux thing. [1] https://specifications.freedesktop.org/basedir-spec/latest/ https://specifications.freedesktop.org/basedir-spec/latest/ [2] https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/XDGConfigFolders?action=show&redirect=GnomeGoals%2FXDGConfigFolders https://wiki.gnome.org/action/show/Initiatives/GnomeGoals/XD...
- deleted 3y ago
  [deleted]
- halostatue 3y ago
  Thank you for the information.
RamblingCTO 3y ago
And who's using that? You'd break user expectations with that. Sometimes it's not about being most correct.
- halostatue 3y ago
  Yet…that is exactly the argument of the original post. The banner argument is that VIM is wrong because it doesn’t use `~/.config/vim` and instead uses `~/.vim` … which it has used since before XDG was created. Vim also doesn’t use ~/.vim` on Windows (and the files aren't `.vimrc` and `.gvimrc`, but `_vimrc` and `_gvimrc`. User expectations differ. The correct place to put application detritus is `~/Library` on macOS (`/Library` if it’s system-level with no user-level). I am surprised when a cross-platform library uses `~/Library` instead of XDG, but I am not unhappy with it. Frankly, most programs should have a command like `show-config-paths` (`--show-config-paths`) so that you can see where the configuration, caches, etc. are on the platform you’re on, and possibly be told (a) whether they are overridden from default and (b) how to override them. It would be useful to have that output for both human and machine reading.
  - IggleSniggle 3y ago
    I agree 100% on having a command to this effect. I always make sure that there is a command to show the currently resolved configuration location, as well as printing out configuration (minus secrets) when the application starts in debug mode. Furthermore, when you do '--help', whenever it's half-way reasonable, I will show you what your currently resolved settings are for any flags/variables/configs next to the corresponding flag, as well as the default value. I actually don't know why this isn't common.
ClikeX 3y ago
Has a MacOS dev, I'd prefer config like this in my home directory so I can easily access it between MacOS and Linux. My expectation for CLI tools is that config is in $HOME/.config/.
- josephd79 3y ago
  I agree, as of right now all my CLI tools are in $HOME/.config. Do you have some that are not?
saagarjha 3y ago
~/Library/Application Support is typically used for GUI applications. Using XDG seems reasonable for CLI tools?

exceptione 3y ago

Congratulations, you are in the top 10% for being a professional developer, correcting mistakes and not coming up with shitty excuses. If people from this thread took notice we all could have a clean $HOME and there would be no need for this non-discussion. As you found out, it is incredibly easy to conform to the spec.

rascul 3y ago
I had a clean $HOME before XDG came around. Now it's a mess.
- wink 3y ago
  That makes no sense. You should at most have a single directory `~/.config` more and I suppose 90% of the tools writing or reading there could be configured to use ~/.${TOOL}rc
  - SAI_Peregrinus 3y ago
    XDG didn't (IMO) make things worse, but it also didn't help as much as it should have. My `~/.config` is the largest subdirectory of `~`, because every Chromium/Electron-based application uses `${XDG_CONFIG_HOME}/$APP_NAME/Service Worker/CacheStorage` and `${XDG_CONFIG_HOME}/$APP_NAME/Cache` (and a few other cache directories) instead of sticking those in `${XDG_CACHE_HOME}/$APP_NAME`.
    - exceptione 3y ago
      Have you filed a bug report?
      - deviantintegral 3y ago
        Open since 2016! https://github.com/electron/electron/issues/8124 https://github.com/electron/electron/issues/8124

buttercraft 3y ago

Any particular reason for the cryptic, two letter file name instead of something descriptive?

halostatue 3y ago
op -> [o]ne [p]assword. It matches the command name.