bug: can no longer store global tool-versions files in subdirectories conveniently

[georgekaz]

Describe the Bug

This commit (711ad99) mean that storing global versions files in a sub-directory no longer works in combination with local versions files in the current folder.

e.g. I've always stored all my global tool-versions files in a subdirectory of $HOME called asdf-tool-versions and set ASDF_DEFAULT_TOOL_VERSIONS_FILENAME=asdf-tool-versions/.tool-versions.$1 (where $1 is obviously variable)

This way, asdf global x y would update $HOME/asdf-tool-versions/.tool-versions.x but asdf local x y would create a file called .tool-versions in the current directory .

After the above mentioned commit, either every local directory needs to also have a asdf-tool-versions sub-directory, or all global configs must be in the root of $HOME.

One option maybe to add ASDF_DEFAULT_GLOBAL_FILE_FOLDER or suchlike, or just revert.

Steps to Reproduce

1. Create directory in home folder called asdf-tool-versions
2. Export ASDF_DEFAULT_TOOL_VERSIONS_FILENAME=asdf-tool-versions/.tool-versions
3. Change to a directory other than home e.g. /tmp
4. asdf global x y should change $HOME/asdf-tool-versions/.tool-versions
5. asdf local x y results in /opt/asdf-vm/lib/functions/versions.bash: line 67: /tmp/asdf-tool-versions/.tool-versions.default: No such file or directory

Expected Behaviour

asdf local x y should change /tmp/.tool-versions

Actual Behaviour

asdf local x y results in /opt/asdf-vm/lib/functions/versions.bash: line 67: /tmp/asdf-tool-versions/.tool-versions.default: No such file or directory

Environment

❯ asdf info
OS:
Linux jaws 5.15.76-1-MANJARO #1 SMP PREEMPT Sat Oct 29 14:22:16 UTC 2022 x86_64 GNU/Linux

SHELL:
zsh 5.9 (x86_64-pc-linux-gnu)

ASDF VERSION:
v0.10.2

ASDF ENVIRONMENT VARIABLES:
ASDF_DEFAULT_TOOL_VERSIONS_FILENAME=asdf-tool-versions/.tool-versions.default
ASDF_DIR=/opt/asdf-vm

asdf plugins affected (if relevant)

Not plugin specific

[jmromer]

A configuration setting to support XDG-compatible configuration paths would resolve this

[hyperupcall]

This issue should be closed because it is a duplicate of #1308. Justification of new behavior can be found in that issue. XDG Base Directory compliance can be found at #687.