cwd can potentially be a symlink, which breaks asdf logic.
The following command will fail to resolve the path correctly:
env - PWD=/proc/self/cwd PATH=$HOME/.asdf/shims:/bin ruby --version
This first resolves the real path of cwd before continuing to search
for a .tool-versions file
Noticed we had some duplicated logic for finding the
plugins installation path. This caused the bug described
by #213 where the installation command and the find_executable_path
were using different paths.
Fixes#213
Running "asdf current ruby" before installing any Rubies gave me:
/Users/henrik/.asdf/lib/utils.sh: line 73: [: !=: unary operator expected
No version set for ruby
Before this patch, with a `.tool-versions` file like:
```
lfe ref:master
```
`get_preset_version_for` would return `ref` instead of `ref:master`.
Same was happening for `path:` versions. Actually there was PR #95
on which I based my changes but instead of using space as delimiter
I went for using `|` which would be a lot more weird if present as
part of a file path, this also allows to specify paths which have
spaces which are much more frequent.
Closes#94#95
For example if asdf finds that the `ASDF_FOO_VERSION` is
defined in the current environment it will override the
version of `foo` from the `.tool-version` file.
Closes#49
- Remove plugin shims when last version is uninstalled.
- Remove shims on plugin-remove
When the latest version of a tool is uninstalled,
Remove the plugin shims (marked with metadata at #122)
Also found lots of missing tests and added them.
Closes#67
Without this patch, asft was not able to determine the tool version
for a project located outside the user's HOME directory.
```
/work/project/
/home/me/.tool-versions
```
This changeset lets asdf find the global version stored at
$HOME/.tool-versions when the directory traversal from
the project dir was not able to find a suitable version.
