shibukawa / configdir Goto Github PK

Config files sometimes contain secret data. In this case it would nice to predefine the file and folder permission. Something similar to umask.
In addition the package could provide a function that checks and fixes the permission.

Currently using this lib to build a snap compatible command line tool and while declaring the snap plugs for personal-files I found that it does not consider those paths.

Output of QueryFolders() on an unconfined binary:

/home/adrian/.config/pushover-cli
/etc/xdg/xdg-plasma/pushover-cli
/etc/xdg/pushover-cli
/usr/share/kubuntu-default-settings/kf5-settings/pushover-cli

which is fine. As soon as I use the same method inside a snapped binary:

/home/adrian/snap/pushover-cli/x1/.config/pushover-cli
/etc/xdg/xdg-plasma/pushover-cli
/etc/xdg/pushover-cli
/usr/share/kubuntu-default-settings/kf5-settings/pushover-cli

After I connect the personal-files interface on my snap it still does not consider $HOME/.config a valid directory.

Maybe it could consider /home/$USER as a possible location on linux, even if $HOME is present, as those two can differ in a confined deployment.

I cant use LocalPath as the order is mixed. If I read or write a config, I prefer $HOME/.config over $HOME/snap/ and only if write access to former is not possible, I want to write to $HOME/snap. That does not mean that it should not detect a possible read-only config file in $HOME/.config.

Any idea how to handle this gracefully?

The environment variable can be broken on systems. We came across a setup with the users directory on a network drive H:\ and APPDATA not resolving to anything.

I am surprised myself how anything works on this system, but I guess Windows's own API which one is supposed to use does work:
https://stackoverflow.com/questions/5920853/how-to-open-a-folder-in-appdata-with-c

This is the same used by QT: https://code.woboq.org/qt5/qtbase/src/corelib/io/qstandardpaths_win.cpp.html

I'd recommend using this API call get the directory.

I don't have data on this but I am pretty sure that most people place scripts in unix style directories rather than /Library. As such, quite a few people probably use XDG_CONFIG_HOME even on MacOS. Yet this library doesn't support that, which means every CLI app relying on this library also doesn't (jesseduffield/lazygit#641)

Just pulled this in and got the following output.

$ go get -u github.com/shibukawa/configdir
go: finding github.com/shibukawa/configdir latest
go: downloading github.com/shibukawa/configdir v0.0.0-20170330084843-e180dbdc8da0

Cutting a release for v1.0 or some minor variant would be nice to have.