-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unclutter HOME by conforming to XDG specification #17
Comments
Addresses #17 - Moves `.tmux.conf` byobu config file to `.config/byobu` in this repo - Adjusts the symlink in Makefile After this change, and if `BYOBU_CONFIG_DIR` uses `XDG_CONFIG_HOME`, it is safe to re-link the config file and drop `~/.byobu` directory.
Addresses #17 - Moves `.direnvrc` from the root to `.config/direnv/` - Respectively, after new symlink will point to `XDG_CONFIG_HOME/direnv/direnvrc` - Makefile is updated to create the directory and make this symlink
Addresses #17 - Defines `CRAWL_DIR=$XDG_CONFIG_HOME/crawl/` both in `.zshenv` and Makefile - Updates installation in Makefile to ensure the directory exists Once new `CRAWL_DIR` is exported, it is safe to move the contents of `~/.crawl` into `CRAWL_DIR` and delete the old directory. The game will read the data as long as `CRAWL_DIR` is in scope.
Addresses #17 - Moves `.gitconfig` from the root to `.config/git/` - After new symlink is created, it will point to `XDG_CONFIG_HOME/git/config` - Makefile is updated to create the directory and make the symlink
Addresses #17 - Adds an alias for `wget` that adds `--hsts-file` option pointing to file in `XDG_CACHE_HOME` - The alias is added to `.zshenv` even though it's not a good practice to modify command behavior in it - The rationale is that we want to prevent all executions from creating the file in `$HOME`, other that that it still behaves as regular wget After setting this alias it's safe to just move/rename existing `~/.wget-hsts` file to `$XDG_CACHE_HOME/wget-hsts`.
Addresses #17 - Moves `.p10k.zsh` to `.config/zsh/` - Updates Makefile to create new symlink pointing to `XDG_CONFIG_HOME/zsh/p10k.zsh` - Sets `POWERLEVEL9K_CONFIG_FILE` to this symlink in `.zshrc` and disables configuration wizard After re-linking the config file reload the shell.
|
Addresses #17 - Sets `KAGGLE_CONFIG_DIR` to `$XDG_CONFIG_HOME/kaggle` After reloading shell (i.e. `KAGGLE_CONFIG_DIR` is set) it should be safe to just move/rename `~/.kaggle` to `KAGGLE_CONFIG_DIR`.
NSS data in Migration commands: mkdir -p $XDG_CONFIG_HOME/pki/nssdb $XDG_DATA_HOME/pki/nssdb && \
mv $HOME/.pki/nssdb/pkcs11.txt $XDG_CONFIG_HOME/pki/nssdb && \
mv $HOME/.pki/nssdb/*.db $XDG_DATA_HOME/pki/nssdb && \
rm -r $HOME/.pki |
After further testing Chrome does seem to re-create Adding an item for it to the list. |
Adding an item for it to the list. |
Addresses #17 - Defines `LESSKEY` environment variable pointing to `XDG_CONFIG_HOME` - Defines `LESSHISTFILE` environment variable pointing to `XDG_DATA_HOME` Notes: - `less` as of version 600 should support XDG out-of-the-box and thus this environment setup could be later deprecated - Additionally, `less` should pick the history file from `XDG_STATE_HOME` as well - this env var is currently undefined tho After reloading shell make sure to create appropriate directories and move/rename existing files.
At least partial fix could be export VSCODE_EXTENSIONS="$XDG_DATA_HOME/vscode/extensions" or setting a global alias or a script for running The |
base16-shell has
Best approach would be to open a PR. Alternatively, for now and to test, Note: Probably best place to use for these would be either |
Addresses #17 - Adds TRAVIS_CONFIG_PATH environment variable pointing to XDG_CONFIG_HOME Once TRAVIS_CONFIG_PATH is set, it is safe to move the contents of `~/.travis` to `$TRAVIS_CONFIG_PATH`.
Addresses #17 - Re-defines `GEM_HOME`, newly defines `GEM_SPEC_CACHE` and enables `GEM_BIN` environment variables - Makes sure these and `TRAVIS_CONFIG_PATH` are also defined in Makefile - Changes ruby (and gem) installation tool from `snap` to `apt`. This change is necessary because `gem` from `snap` does not respect custom `$GEM_HOME` even if used as `gem install --no-user-install`, see: https://stackoverflow.com/a/70101849 - Changes `travis` installation in Makefile by adding `--no-user-install` so that it doesn't create `~/.gem` Note that this is a breaking change due to new installation method. Since the only ruby tool currently used is *travis*, and because splitting and moving `~/.gem` files would be cumbersome, the easiest migration is to simply uninstall ruby `sudo snap remove ruby`, drop `~/.gem` directory and re-install both ruby and travis.
Addresses #17 - Adds and symlinks custom `.config/maven/settings.xml` that uses `XDG_CONFIG_HOME` for `localRepository` - Adds an alias `mvn -gs`, that points to this symlink as the global settings file, to `.zshenv` - This is far from being perfect, but it's the only (official) workaround, see: https://issues.apache.org/jira/browse/MNG-6603 After linking `settings.xml` and reloading shell to get the alias in scope, one can migrate current contents of `~/.m2` and then drop it.
Addresses #17 - Adds `GRADLE_USER_HOME` pointing to `XDG_DATA_HOME` to `.zshenv` - According to gradle/gradle#17756 gradle still might create `~/.gradle/daemon` After reloading shell to set `GRADLE_USER_HOME`, one can just migrate the data by running `mv ~/.gradle $XDG_DATA_HOME/gradle`.
Addresses #17 - Adds `KSCRIPT_CACHE_DIR` pointing to `XDG_CACHE_HOME` to `.zshenv` - Note: out-of-the-box support is still an open issue
It's not quite clear which XDG directories one should use (except obvious So it should be sufficient to just run mv ~/.ipython $XDG_CONFIG_HOME/ipython |
Addresses #17 - Adds `JUPYTER_CONFIG_DIR` pointing to `XDG_CONFIG_HOME` to `.zshenv` - Documents situation around IPython - NOte: out-of-the-box XDG support is still an open issue - see: jupyter/jupyter_core#185 After reloading the shell (i.e. once `JUPYTER_CONFIG_DIR` is in scope), one can simply move/rename `~/.jupyter` to `JUPYTER_CONFIG_DIR`.
Addresses #17 - Adds `RUSTUP_HOME` and `CARGO_HOME` pointing to `XDG_DATA_HOME` - Note: out-of-the-box support is still an open issue for both `rustup` and `cargo` After reloading the shell (i.e. if both env vars are in scope), one can just move/rename `~/.rustup` and `~/.cargo` to appropriate dirs in `XDG_DATA_HOME`.
Addresses #17 - Changes `STACK_ROOT` to point to `XDG_DATA_HOME` in `.zshenv` - Updates location and linking of stack `config.yaml` This is a breaking change for existing projects, so the best migration is simply dropping the global cache and reinstall: 1. Drop the old `~/.stack` 2. Reload shell to get new `STACK_ROOT` 3. Create new config symlink: `make links` 4. Reinstall tools: `make haskell-tools` Stack projects should be cleared with `stack purge` and rebuilt.
GHC should support XDG since This means that older versions probably will keep using/creating As a potential workaround (perhaps just for older GHC versions), one could set a global alias ghci="ghci -flocal-ghci-history" Although, this might pollute the |
Addresses #17 - Changes `GOPATH` to point to `XDG_DATA_HOME`
Addresses #17 - Adds `XDG_BIN_HOME` environment variable for user's binaries and adds it to appropriate places in Makefile - Introduces `GHCUP_USE_XDG_DIRS` to enable `gucp`'s XDG support, see: https://www.haskell.org/ghcup/guide/#xdg-support - Updates path for sourcing `ghcup` env in `.zshrc` - Adds potential deprecation note for `make stack` This change requires reinstall, however it does not seem to break existing stack projects. Migration can look as follows: 1. `~/.ghcup`, `~/.cabal` and `~/.ghc` can be dropped 2. Reload shell to bring `GHCUP_USE_XDG_DIRS` in scope 3. Reinstall with `make ghcup` with HLS and `stack` as well - `.zshrc` update is not necessary as it's part of this commit 4. Reload shell again to source ghcup's env Known issues: - Shell completions for `ghcup` don't seem to work (could have been a pre-existing issue) - Stack must now be updated via `ghcup` (according to a post-install log message)
Even with |
Addresses #17 - Changes the location of `~/vm` to conform to XDG specification - Updates `DEBIAN_ISO` in Makefile to currently published one
Addresses #17 - Adds `NPM_CONFIG_USERCONFIG` that points to custom `npmrc` in `XDG_CONFIG_HOME` - Adds and symlinks custom `npmrc` that defines prefix and other node/npm locations in XDG dirs - Updates `make nodejs` to install node/npm to `XDG_DATA_HOME/npm` - Adds new `XDG_DATA_HOME/npm/bin` dir to the `PATH` - Adds `NODE_REPL_HISTORY` env var pointing to `XDG_DATA_HOME` This change requires clean reinstall, however at least coc seem to work after that. Old install uses following system files and dirs which should be dropped - `/usr/local/bin/{corepack,node,npm,npx}` - `/usr/local/include/node/` - `/usr/local/lib/node_modules` - `/usr/local/share/doc/node` - `/usr/local/share/man/man1/node.1` - `/usr/local/share/systemtap/tapset/node.stp` and potentially there might be an old snap installation of node. After that one can do a fresh installation: 1. Reload the shell to bring new env vars into scope 2. Symlink the `npmrc`: `make links` should do 3. Reinstall node with the new prefix: `make nodejs`
Other than that |
Therefore, the best option to get rid of |
Since the shell in use is mkdir -p "$XDG_STATE_HOME"/bash
mv ~/.bash_history $XDG_STATE_HOME/bash/history and add this line to export HISTFILE="${XDG_STATE_HOME:-$HOME/.local/state}/bash/history" |
Addresses #17 - Changes `KREW_ROOT` in `.zshenv` to point to `XDG_DATA_HOME` - Defines `KREW_ROOT` in Makefile to make `binenv` install krew to this custom location (not tested) Migration is quite straightforward: 1. Reload shell to update environment variables 2. Move/rename krew: `mv ~/.krew $KREW_ROOT` 3. Adjust existing symlinks to `$KRE_BIN`: e.g. `ln -svf $KREW_ROOT/store/ctx/v0.9.4/kubectx $KREW_BIN/kubectl-ctx`
Addresses #17 - Adds `CUDA_CACHE_PATH` environment variable to `.zshenv` and points it to `XDG_CACHE_HOME` Since the directory is a cache, there are generally two options how to migrate: - Simply drop the `~/.nv` directory - Reload shell and move/rename it: `mv ~/.nv $CUDA_CACHE_PATH`
Addresses #17 - Defines `KERAS_HOME` in `.zshenv` and points it to `XDG_CONFIG_HOME` Known issues: - There might be an issue with `tf.keras` not respecting `KERAS_HOME` - However, after a quick check this seems fine Migration guide: 1. Reload the shell (or define `KERAS_HOME`) 2. Move/rename the directory: `mv ~/.keras $KERAS_HOME`
Updates #17 - Changes the location of keras data from `XDG_CONFIG_HOME` to `XDG_CACHE_HOME` - This is done by modifying `KERAS_HOME` in `.zshenv` - The reasoning behind this change is that despite the fact that one can specify the download path for keras datasets, it's always relative to `$KERAS_HOME/datasets`. So storing such a large cache in `XDG_CONFIG_HOME` would not be optimal. To apply this change one can simply move the directory.
Tested by removing the file and running |
Addresses #17 - Defines an `sbt` alias which uses `-ivy` and `-sbt-dir` options pointing to `XDG_DATA_HOME` - This alias is set in `.zshenv` even though this should typically be part of `.zshrc`. The reason is that it should prevent `sbt` to create `~/.sbt` and `~/.ivy2` for all commands. - An alternative approach could be to set `SBT_OPTS` Migration has just two simple steps: 1. Reload the shell to bring the alias into scope 2. Move/rename sbt and ivy2 dirs from `HOME` to `XDG_DATA_HOME`
Addresses #17 - Adds `JDK_JAVA_OPTIONS` and additionally `JAVA_OPTS` environment variables to `.zshenv` which define `-Djava.util.prefs.userRoot` option pointing the java config dir to `XDG_CONFIG_HOME` - This Workaround is based on https://wiki.archlinux.org/title/XDG_Base_Directory with the change to `JDK_JAVA_OPTIONS` which should be supported for JDK since Java 11 - The extra `JAVA_OPTS` might be picked up by some apps - Note: This change needs testing and potential update. In order to migrate one just needs to reload the shell (to export these variables) and move/rename `~/.java` to `$XDG_CONFIG_HOME/java`.
Addresses #17 - Forks `profile_helper.sh` script from `base16-shell` and modifies it to support XDG specification - This script is symlinked from `.config/base16-shell` in this repo back to `$BASE16_SHELL_HOME` where the official repo is cloned - The main change is that `~/.base16_theme` and `~/.vimrc_background` can now be placed to `XDG_STATE_HOME/base16-shell` directory - The script also makes sure this XDG directory is created if it does not yet exist - Furthermore, if XDG path is used then these filed do not contain the leading dot in there name - i.e. `base16_theme` instead of `.base16_theme` - For backwards compatibility, if there are existing `~/.base16_theme` and/or `~/.vimrc_background` then these are used instead of XDG ones - Additionally, `init.vim` is updated to automatically pick up either `~/.vimrc_background` or `$XDG_STATE_HOME/base16-shell/vimrc_background` and source it to set the `colorscheme` instead of a hard-coded value Migration can be done in two ways: 1. First link new `profile_helper.sh` with `make links` 2. Reload the shell 3. Then one can either make the `XDG_STATE_HOME/base16-shell` and move/rename `~/.base16_theme` and `~/.vimrc_background` to it, or just re-pick a theme with `base16_<theme>`
- `lynx` was not used for a while now and as such doesn't have to be installed along other apps/libs in Makefile - Note that this change does not uninstall `lynx`, to do so just run `sudo apt purge lynx` - `~/.lynxrc` can also be dropped, this additionally simplifies solving issues with XDG migration (as these are not relevant anymore), see: #17
Addresses #17 - Moves the export of `SDKMAN_DIR` from `.zshrc` to `.zshenv` and updates the path to use `XDG_DATA_HOME` instead of `HOME` - Analogously updates this variable in Makefile so that it's picked up by `make sdk` - i.e. install sdkman to `XDG_DATA_HOME` - Additionally, makes the installation not to update rc files. This update is not necessary since we're using custom `.zshrc` - See: https://sdkman.io/install Migration can be done as follows: 1. Reloading the shell to bring updated `SDKMAN_DIR` into scope 2. Moving/renaming the directory: `mv ~/.sdkman` $SDKMAN_DIR
Addresses #17 - Changes the location of `undodir` in `init.vim` to use `XDG_STATE_HOME` In order to migrate one can simply move/rename current `~/.vimdid` to the `XDG_STATE_HOME` or just delete it if the undo history can be lost.
Addresses #17 - Adds `PYTHONSTARTUP` environment variable to `.zshenv` pointing to custom `startup.py` file (bootstraps interactive Python) - `startup.py` is symlinked to `XDG_CONFIG_HOME/python` and contains cherry-picked section of an open PR that adds XDG support to the `site` module (used to customize interactive Python) - This is a workaround to redirect the hard-coded history file `~/.python_history` to `$XDG_STATE_HOME/python/history` - Tested for both system python and virtual environment Migration takes following steps: 1. Reload the shell to bring `PYTHONSTARTUP` into scope 2. Symlink `startup.py`: `make links` 3. Move/rename the history file (or just drop it): `mv ~/.python_history $XDG_STATE_HOME/python/history`
Addresses #17 - Adds custom environment variable `SCALA_HISTFILE` to `.zshenv` and points it to `XDG_STATE_HOME` - Defines two aliases for `scala` and `spark-shell` which both set an option `-Dscala.shell.histfile` using the `SCALA_HISTFILE` - Note that this works only for Scala 2 (Spark runs Scala 2) and Scala 3 will still create `~/.dotty_history` Migration can be done as follows: 1. Reload shell to bring aliases and `SCALA_HISTFILE` into scope 2. Move/rename the history file: `mv ~/.scala_history $SCALA_HISTFILE` (make sure the target dir exists prior to running it)
Scala 3 (dotty), does not recognize After some googling, I've not found any relevant resources on this issue - i.e. how to change the default location where the REPL history is stored. |
Addresses #17 - Adds `MINIKUBE_HOME` environment variable to `.zshenv` and Makefile and points it to `XDG_DATA_HOME` Known issues: - `minikube` creates a further `.minikube` directory in `MINIKUBE_HOME` for whatever reason Migration can be done as follows: 1. Reload the shell to bring `MINIKUBE_HOME` into scope 2. Start minikube (`minikube start --driver=kvm2`) to re-initialize it and just drop `~/.minikube` (tested) or possibly just move the old directory `~/.minikube` to `MINIKUBE_HOME` (not tested)
- Changes the installation method for `aws-vault` in Makefile from custom one to `binenv install` - Adds new `AWS_*` environment variables to ensure aws-cli and aws-vault conform to XDG specification (out-of-the-box support is still an open issue for both tho) - Note that these two changes address issue #5 and #17 respectively In order to migrate just 1. Reload current shell 2. Move/rename `~/.aws` content according to newly added env vars
This commit adds a make target `disable-sudo-admin-file` which generates custom sudoers config file that disables the `admin_flag`. The effect of this change is that `.sudo_as_admin_successful` should no longer appear in HOME. This solves the respective part of issue #17. Note that this solution only works with `sudo >= 1.9.6` and that there are no additional steps necessary, just run the make target and remove the file from HOME.
This commits adds an alias for `nvidia-settings` witch custom config file location under XDG_CONFIG_HOME to conform to the XDG specs (see issue #17). Migration: 1. Reload current shell to set the alias 2. Move the config file from HOME to `$XDG_CONFIG_HOME/nvidia-settings` Known issues: - This patch does not fix the behavior when running `nvidia-settings` from the Gnome menu. The config file is in this case still created in HOME.
c7edcf0 introduces an alias for A possible hack to solve the remaining issue could be to modify |
This commit makes the `nvidia-settings` application use custom location of the configuration file when running it from the Gnome menu. Specifically this patch: - Adds and exports `NVIDIA_SETTINGS_RC` environment variable - Adds new make target `nvidia-settings-rc-xdg-path` which edits the `Exec` entry in `/usr/share/applications/nvidia-settings.desktop` to use the same `--config` option as the zsh alias - Adds new section describing this manual configuration to README In order to apply these changes just reload current shell and run the newly added make target. Note that this fixes the remaining issues with `nvidia-settings` and concludes this part of issue #17.
1e95ce3 fixes remaining issue with the Gnome desktop make nvidia-settings-rc-xdg-path command to edit the desktop entry accordingly. |
4f7f79b removes the auxiliary |
1f2a9a8 is an attempt to get rid of Note that it still might get created, because the overshadowing |
9872551 moves (and solves the issue of) the |
b3c819b splits and moves |
8d2bd51 is an attempt to get rid of Note that the |
fe59105 removes |
Unclutter
$HOME
directory by moving config files toXDG_CONFIG_HOME
,XDG_DATA_HOME
and/orXDG_CACHE_HOME
.See Arch's docs on XDG support.
This is a tracking issue for following apps/tools:
~/.gitconfig
- move to$XDG_CONFIG_HOME/git/config
direnv
: https://github.com/direnv/direnv#the-stdlib~/.binenv
byobu
- see docs onBYOBU_CONFIG_DIR
~/.oh-my-zsh
.p10k.zsh
: usePOWERLEVEL9K_CONFIG_FILE
~/.poetry
~/.npm
ghcup
(ghc
,cabal
) see: https://www.haskell.org/ghcup/guide/#xdg-supportstack
~/.helm
~/.minikube
~/.kube
-hard-coded, there's an open issuesetKUBECONFIG
andKUBECACHEDIR
~/.rustup
- not yet supported out-of-the-box, setRUSTUP_HOME
~/.cargo
- not yet supported out-of-the-box, setCARGO_HOME
~/.sdkman
and possibly managed JVM components: Java, Scala, Kotlin, kscript, maven, gradle~/.java
~/.sbt
and~/.ivy2
- still an open issue but there's a workaround runsbt
with-ivy
and-sbt-dir
pointing toXDG_DATA_HOME
locations~/.kscript
- setKSCRIPT_CACHE_DIR
~/.m2
- use customsettings.xml
and follow current workaround~/.gradle
- setGRADLE_USER_HOME
~/go
- not yet supported out-of-the-box, setGOPATH
~/.gem
(ruby)~/.travis/
~/.aws
- setAWS_SHARED_CREDENTIALS_FILE
andAWS_CONFIG_FILE
less
- should be supported in newer versions or useLESSHISTFILE
andLESSKEY
~/.wgetrc
,~/.wget-hsts
~/.ipython
- supported (i.e. files are picked up) if manually moved to XDG dirs, see 8.x release notes~/.jupyter
- not yet supported out-of-the-box, setJUPYTER_CONFIG_DIR
~/.kaggle
- setKAGGLE_CONFIG_DIR
~/.crawl
~/.thunderbird
- hard-coded: https://bugzilla.mozilla.org/show_bug.cgi?id=735285~/.mozilla/
~/.pki
- still created by vscode, works for firefoxChrome:~/.pki
~/.pki
, possibly~/.dotnet/corefx
~/.gnome
- generallyxdg-utils
, currently hard-coded inxdg-desktop-menu
, used e.g. by chromium, PR with fix exists, however it is not merged yet~/.vscode
lynx:~/.lynxrc
, possibly~/.lynx_cookies
- useLYNX_CFG
orLYNX_CFG_PATH
(see https://linux.die.net/man/1/lynx)~/.gnupg
- useGNUPGHOME
but check the notes (needs additional tweak)~/.vimrc_background
hard-coded in$BASE16_SHELL_HOME/profile_helper.sh
and.base16_theme
symlinked~/.nvidia-settins-rc
- created bynvidia-settings
, not yet supported out-of-the-box, set an alias withnvidia-settings --config ...
~/.nv
(CUDA) - setCUDA_CACHE_PATH
~/.keras
- setKERAS_HOME
, but there is/was an issue withtf.keras
~/sklearn_learn_data
- setSCIKIT_LEARN_DATA
~/tensorflow_datasets
- setTFDS_DATA_DIR
~/snap/
- XDG spec support is "planned work"~/.krew/
- modifyKREW_ROOT
and set it for installation, see docs~/.yarn/
- should be partially supported, workaround for~/.yarnrc
is to define an alias with--use-yarnrc
(if such exists) usingXDG_CONFIG_HOME
~/.sudo_as_admin_successful
- withsudo >= 1.9.6
one can setadmin_flag
in/etc/sudoers
~/.redhat
- contains single fileanonymousId
, most likely created byvscode
's telemetry~/.vimdid
~/.bash_history
- setHISTFILE
in.bashrc
similarly as it's done in.zshrc
~/.python_history
- hard-coded, there are some workarounds but it seems that only from python itself~/.scala_history
- can be changed withscala -Dscala.shell.histfile=...
, note: checkspark-shell
, applies to Scala 2 orSBT_OPTS
could work too~/.dotty_history
- applies to Scala 3~/.selected_editor
- used byselect-editor
, should not be necessary withEDITOR
set~/.docker
- setDOCKER_CONFIG
~/.debug
- created and used byperf
,currently hard-coded, configured viaperf config --system buildid.dir=...
The text was updated successfully, but these errors were encountered: