just starting to make a tracking ticket so people can share research and ultimately make the correct rule

I am using our own TROMjaro.com operating system and I got sick of these .files especially since I test hundreds of applications for our distribution. If you make an AUR for it so I can easily install and manage it (updates and all) I will test this a lot, since I am installing a ton of applications to test for our distro :).

Could be very useful for this little app to get some proper testing.
Thanks a lot for doing this!

just starting to make a tracking ticket so people can share research and ultimately make the correct rule

When I try to open antidot-darwin-amd64.6-amd64 binary on Big Sur (note: I suppose it will fail on Catalina too.), the system blocks it because it comes from 'unidentified developer'. Well-know workaround with right click doesn't help, because (wild guess!) the binary isn't opaqued into .app directory and it doesn't know, how to deal with it.

I tried:

• running it directly from shell;
• running it with open command;
• right-click and select 'Open' from submenu.

The results are here. Mac is, obviously, the one with Intel - I wouldn't try amd64 binary on M1 ;-)

In #107 a bug runs over set environment variables and only keeps 2 at a time. This is very bad since these variables are not recoverable without restoring the dotfiles back in the home directory. I will need to keep a separate store that will generate the different formats (bash, fish, zsh etc.).

issue filed seemoo-lab/opendrop#60

it is hardcoded in config.py for now

I recently upgraded to Ubuntu 20.10 and a directory $HOME/.pipewire-media-session appeared

Ubuntu 20.10 uses pipepire 0.3.10. In the page below, 0.3.11 supports XDG standards. It says that all is needed to migrate is to move the files.

https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/0.3.11

So migration should only occur with version 0.3.11 and later.

I was running antidot 0.4.2 until yesterday, I upgraded to 0.6.2

On the next boot, some migrated files appeared again. It wasn't until today that I noticed that none of the migrated environment variables were set anymore.

I just checked $HOME/.local/share/env.sh and it was now empty.

Has anyone experienced this? Do I have to start again with this?

I have a test system so I wanted to try antidot on that. Before I ran antidot clean I ran antidot init and added to contents to my .bashrc file

Upon opening a new terminal, it said
bash: /home/rob/.local/share/antidot/alias.sh: No such file or directory
bash: /home/rob/.local/share/antidot/env.sh: No such file or directory

Should these get created when antidot init is run (if they don't exist)?

After running antidot clean I opened a new terminal and got
bash: /home/rob/.local/share/antidot/alias.sh` as only environment variables were needed during this migration, seems that only env.sh was created

Should these get created when antidot init is run (if they don't exist)?

I think I should remove the log formatting and quiet all debug logs (unless --verbose is passed). I also want a nicer prompt and action printing.

For now we keep aliases and environment variables in bash format. We should also support Zsh, Fish and other popular shells.

For example, with zsh:

fmt.sprintf("export XDG_CONFIG_HOME=${XDG_CONFIG_HOME:-%s}", xdg.ConfigHome)

We should add more rules to rules.yaml.

The main source right now is this Arch Linux wiki which is updated from time to time. There are 3 tables on that page: supported, partial and hardcoded. We want to first add the items from the partial table and maybe later look at hardcoded.

There is also some stuff in this Reddit post which may not be in the Arch wiki above.

I did an antidot clean earlier and .gnupg got migrated

I ran gpg and then ~/.gnupg got created as env.sh hadn't been reloaded to set GNUPGHOME

I run source .profile (where I have $(antidot init) and nothing more was loaded, as ANTIDOT_INIT=1 was set, it wasn't loaded again.

In the end, I restarted my computer and it loaded the new variables and it was all working correctly. Is there a way I can load them without restarting my computer?

.. or instruct them of how to create their own rules in kvstore.json.

I propose we add some comments to the beginning of env.sh and alias.sh:

## WARNING: antidot manages this file internally and will overwrite it
## DO NOT EDIT THIS FILE YOURSELF
# To set your own environment variables, edit `antidot/kvstore.json` and add key-value pairs
# Something something please open a pull request if antidot does not know how to handle a dotfile that we can clean up

I would go further and say that env.sh and alias.sh have no reason to exist, because all the actual information about what to do is stored in kvstore.json as far as I can tell so far. A better implementation would be to have antidot init parse kvstore.json and produce the necessary information to stdout: this would enable supporting more non-POSIX shells, such as ion, more easily.

Right now our release workflow is kind of broken and half manual. I would like to have a workflow that is creating a PR with the changes to CHANGES.md while creating a draft release. Another step should run application tests with the binaries from the draft release. Once the PR is merged a tag could be set and the release published.

Maybe that's a little overkill but any working automation in that direction will be good enough.

Create a schema and validate the rules file

git already suports XDG standards, though its not default, the global config file just needs moving

git creats $HOME/.gitconfig for global settings, it also supports $XDG_CONFIG_HOME/config/git/config if the file exists otherwise its default falls back to $HOME/.gitconfig

move $HOME/.gitconfig to $XDG_HOME_CONFIG/.config/git/config

I migrated gnupg (from $HOME/.gnupg to $XDG_CONFIG_HOME/gnupg) thIen ran gpg --list-keys and it created $HOME/.gnupg as GNUPGHOME hadn't been set.

What was required at that point was for me to open a new terminal to refresh env.sh and then GNUPGHOME was set.

I think it would be good to either

1. warn the user to close and open the terminal after cleanup migration
   or.
2. source env.sh and aliases.sh after cleanup to load the new variables for immediate use.

Thinking about it, I think the seconds one would be more user friendly as they don't have to do any more to load new variables after cleanup migration

This is just a general dump of files and folders that could be implemented. Each of these should be moved to their own issue

.xsession-errors
.yarnrc
.xsessionrc
.xinputrc
.Xauthority
.wget-hsts
.sudo_as_admin_successful
.profile
.pam_environment
.notable.json
.lmmsrc.xml
.ICEauthority
.gtkrc-xfce
.gitconfig
.face
.emulator_console_auth_token
.dmrc
.bashrc
.bash_logout
.bash_history
.yarn
.wine
.vscode-oss
.tor-browser
.themes
.ssh
.rednotebook
.pki
.notable
.mume
.linuxmint
.java
.icons
.hplip
.gphoto
.gnome
.dbus
.cinnamon

project: https://github.com/bmmcginty/barnard/
issue: bmmcginty/barnard#5
research: can alias barnard='--config ${XDG_CONFIG_HOME}/barnard/config.yaml' as workaround

.pulse-cookie can be safely moved to XDG_CONFIG_HOME/pulse/cookie

Although I have set my envs, they are being reexported in a wrong way. I'm running Zsh.

❯ echo $XDG_CACHE_HOME
/home/rod/.cache
❯ eval "$(antidot init)"
❯ echo $XDG_CACHE_HOME
{XDG_CACHE_HOME:-/home/rod/.cache}
❯ antidot --version
antidot version 0.6.1

❯ pwd
/home/rod/{XDG_DATA_HOME:-/home/rod/.local

Downloaded v0.3.0 for amd64, done antidot update, then tried to run it:

user@debian:~$ ./antidot-linux-amd64 clean
Rule gnupg:
  MOVE   /home/user/.gnupg → /gnupg
  EXPORT GNUPGHOME="${XDG_DATA_HOME}/gnupg"
? Apply rule gnupg? Yes
Failed to run rule gnupg: rename /home/user/.gnupg /gnupg: permission denied

Rule kde:
  MOVE   /home/user/.kde → /kde
  EXPORT KDEHOME="${XDG_CONFIG_HOME}/kde"
? Apply rule kde? (y/N) 

Rule less:
  MOVE   /home/user/.lesshst → /less/history
  EXPORT LESSHISTFILE="${XDG_CACHE_HOME}/less/history"
  EXPORT LESSKEY="${XDG_CONFIG_HOME}/less/lesskey"
? Apply rule less? (y/N) 

That looks very wrong.

BTW. I do not have XDG_CONFIG_HOME actually set.

antidot should detect that and not do silly things.

When software is run via the terminal its working well.

When software is run via a graphical menu like with a desktop environment, then I'm finding that the aliases aren't being used.

I manually setup an alias i $HOME/.loca/share/antidot/alias.sh for dosbox then rebooted just to make sure new setting took place.

It worked when I ran dosbox via the command like, it used the moved config file. When I ran dosbox via the menu, its like it didn't use the alias and used the original config file.

Have you had any experience like this?

This will only happen on some linux distrobutions, not all (so I have read). I don't think anything can be done about it.

After migrating .gnupg, upon reboot it will create a new $HOME/.gnupg directory which has one empty directy in it, though continue to use $XDG_CONFIG_HOME/gnupg when using the gpg command.

I get this with Xubuntu 18.04.5

#107 (comment)

project: https://github.com/cortesi/devd
issue: cortesi/devd#112
research: no obvious way to configure

I don't know where to add this, so I'll try it here.

Nvidia has a directory it uses for cache called GLCache , by default it is stored in ~/.nv

To move this directory the environment variable __GL_SHADER_DISK_CACHE_PATH can be set to $XDG_CACHE_HOME/nv for it to be with the other nvidia cache directories.

Is this where I can add dotfiles for moving?

Thanks,
Rob

Would be nice to show help if no command is specified.

see: https://wiki.archlinux.org/title/XDG_Base_Directory
XDG_STATE_HOME
Where user-specific state files should be written (analogous to /var/lib).
Should default to $HOME/.local/state.

XDG request here claudiodangelis/qrcp#187
project here https://github.com/claudiodangelis/qrcp/

could currently be worked around by settings the alias qrcp='qrcp --config ${XDG_CONFIG_HOME}/qrcp.json' or something like that.

Seems like a better approach to prompt before each action

.Xauthority can be tricky. It can be moved with XAUTHORITY envorment variable, except that there are couple of desktop environments that don't support this.

lightdm is oen, which is the default for Xubuntu. If XAUTHORITY is set, then the user won't be able to login.

A workaround this is to edit the file /etc/lightdm/lightdm.conf and add or edit the line
user-authority-in-system-dir=true
It seems that either this line is not there, or its set to false.

I found it in this page https://askubuntu.com/questions/960793/whats-the-right-place-to-set-the-xauthority-environment-variable

I then deleted $HOME/.Xauthority and rebooted, then it was in /var/run/lightdm/user/Xauthority

I think this variable would have to be set in .profile, so that it would be available during bootup, before .bashrc is processed

I ran software than used theano (a python tool) and it left a directory in $HOME/.theano
From what I understand, its a cache directory to pre-compiled scripts. If its deleted, it will be created on the next time its run.

I think it should belong in $XDG_CACHE_CONFIG/theano

https://theano-pymc.readthedocs.io/en/latest/library/config.html#envvar-THEANO_FLAGS

From the instructions, I moved it using the following envionment variable
THEANO_FLAGS="base_compiledir=$XDG_CACHE_HOME/theano"

We should have a testing framework for ensuring that rules work correctly and we don't break anything. For example, for this cargo rule:

  - name: cargo_home
    description: Rust Cargo home dir
    dotfile:
      name: .cargo
      is_dir: true
    actions:
      - type: migrate
        source: ${HOME}/.cargo
        dest: ${XDG_DATA_HOME}/cargo
        symlink: false
      - type: export
        key: CARGO_HOME
        value: ${XDG_DATA_HOME}/cargo

should be tested like:

1. running cargo commands.
2. ensuring the dotfile is there.
3. running antidot.
4. running cargo commands that interact with it's dotfiles (like reading or writing configuration).
5. ensure the cargo dotfile isn't there and that it did interact with it's dotfile in the new path.

This could be done using the Github Actions platform on both Linux and Mac machines. Also, defining tests should be easy (app installation command, pre-command, post-command, validation command). It could be written in Bash but Go is also an option.

Of course testing interactive applications will pose a bigger challenge or maybe even be too expensive to do.

Sometimes during a migration, a command has to be run e.g. to reset a system running

I just tried to manually migrate gnupg from ~/.gnupg to ~/.local/share/gnupg and for one of my tests, I had to run "gpgconf --kill gpg-agent" before I was able to create a private key. They key agent was still looking in the old directory.

Does antidot support the running of commands during migration?

Just came across this wiki page, seems nice https://wiki.archlinux.org/index.php/XDG_Base_Directory#Supported

it seems to be an alias
$ keychain --absolute --dir "$XDG_RUNTIME_DIR"/keychain womp womp

This can be useful for setting environment variables that need to affect your login shell before your login shell has started. For example Zsh allows you to set a $ZDOTDIR variable to modify where it stores its configuration which can be achieved as follows:

~/.pam_environment:

XDG_CONFIG_HOME   DEFAULT=@{HOME}/.config
ZDOTDIR	DEFAULT=${XDG_CONFIG_HOME}/zsh

I don;t have XDG_DATA_HOME (or any of the XDG directories) set and it gave the output below.

For cargo, it wanted to move it from /home/rob/.cargo to /cargo, shouldn't this be XDG_DATA_HOME/cargo or if XDG_DATA_HOME is not set, ~/.local/share. Does XDG_DATA_HOME fall back to ~/.local.share if its not set?

Rule cargo_home:
MOVE /home/rob/.cargo → /cargo
EXPORT CARGO_HOME="${XDG_DATA_HOME}/cargo"
? Apply rule cargo_home? No

Rule less:
MOVE /home/rob/.lesshst → /less/history
EXPORT LESSHISTFILE="${XDG_CACHE_HOME}/less/history"
EXPORT LESSKEY="${XDG_CONFIG_HOME}/less/lesskey"
? Apply rule less? No

Rule cuda:
MOVE /home/rob/.nv → /nv
EXPORT CUDA_CACHE_PATH="${XDG_CACHE_HOME}/nv"
? Apply rule cuda? No

Rule nvidia-settings:
MOVE /home/rob/.nvidia-settings-rc → /nvidia/settings
ALIAS nvidia-settings="nvidia-settings --config=${XDG_CONFIG_HOME}/nvidia/settings"
? Apply rule nvidia-settings? No

Rule parallel:
MOVE /home/rob/.parallel → /parallel
EXPORT PARALLEL_HOME="${XDG_CONFIG_HOME}/parallel"
? Apply rule parallel? No

Rule rustup:
MOVE /home/rob/.rustup → /rustup
EXPORT RUSTUP_HOME="${XDG_DATA_HOME}/rustup"
? Apply rule rustup? No

I encountered two issues in fish:

1. Applying more than 2 rules with EXPORT would write the third rule over the second in env.fish
2. antidot clean asks me to run eval "$(antidot init)", which in fish it would be eval (antidot init) - but running that gives error fish: 'end' outside of a block

SHELL=/usr/bin/fish
fish, version 3.1.2
antidot version 0.5.0

This is more open for discussion and FYI on my experience as peoples usage needs may vary, depending on computer setup.

I have found that I have to set antidot init in .profile and .bashrc

I have to put it in .profile as __GL_SHADER_DISK_CACHE_PATH has to be set int there after migration. If it isn't, then ~/.nv gets created again

I also set it in .bashrc as if I run antidot clean, then I only have to open a new terminal window to load the new variables and aliases. For .profile I would have to logout then login, or reboot to refresh new variables and aliases after migration

I've been having trouble with adding $(~/bin/antidot init) in .bashrc

When I do, I get the error message
if : command not found
at the beginning of each terminal I open

So for now, I have copied and pasted the code that antidot init prints into my .bashrc file

Am I making an error or is this a bug?
I'm running bash 4.4.20 with xubuntu 18.04.5

.ICEauthority can be moved using the variable ICEAUTHORITY

libice 1.0.10 implements XDG standards, so when $HOME/.ICEauthority is deleted and the computer is rebooted, it creates $XDG_RUNTIME_DIR/ICEauthority
https://gitlab.freedesktop.org/xorg/lib/libice/-/issues/2
https://gitlab.freedesktop.org/xorg/lib/libice/-/commit/b484311c929a1b64966d89da92fafce7263006e1

Now the only problem with this is that I also get an empty $HOME/.ICEauthority as well as the file $XDG_RUNTIME_DIR/ICEauthority being used.

I have submitted a bug report about this
https://gitlab.freedesktop.org/xorg/lib/libice/-/issues/9

When I tried setting ICEAUTHORITY I set it in .profile, I think it would have to set to be available during bootup, before .bashrc gets processed.

it already supports the spec, just need to write a migration

need to test if both the env var AND alias is needed, or just one

$ export GNUPGHOME="$XDG_DATA_HOME"/gnupg
$ gpg2 --homedir "$XDG_DATA_HOME"/gnupg

also from the wiki https://wiki.archlinux.org/index.php/XDG_Base_Directory#Supported apparently this wont work with systemd.

.bash_history can be moved by setting HISTFILE

I know its more of a system file than an application file, are these something you'd consider migrating too?

I suggest moving to $XDG_CACHE_HOME/bash/bash_history
or to
$XDG_CACHE_HOME/bash/history

see "help history" for details