asdf global has issues with relative symbolic links

Created on 1 Oct 2018  路  6Comments  路  Source: asdf-vm/asdf

Steps to reproduce

  1. symlink .tool-versions from a subdir of $HOME (I used stow)
  2. cd to a directory that is not $HOME
  3. asdf global ruby 2.5.1

Expected behavior

Definition for ruby 2.5.1 added to the file symlinked under $HOME/.tool-versions

Actual behavior

/home/user/.local/share/asdf/lib/commands/version_commands.sh: line 37: relative/dir/.tool-versions: No such file or directory

Environment

OS: Kubuntu 18.04

asdf version: v0.5.1

bug

Most helpful comment

@Stratus3D I opened https://github.com/asdf-vm/asdf/pull/625 to fix this, and this appears to work in general, but I'm missing context on why asdf needs to resolve symlinks at all?

Would it not be simpler to let the filesystem do the work, using a symlink path in https://github.com/asdf-vm/asdf/blob/master/lib/commands/version_commands.sh#L40-L45?

All 6 comments

Notably, running this from $HOME works because the relative link works.

This looks like something I missed in https://github.com/asdf-vm/asdf/pull/337.

It looks like my symlink resolution code only works with absolute symlinks. Relative symlinks do not work.

I have this same issue in v0.7.6

@Stratus3D I opened https://github.com/asdf-vm/asdf/pull/625 to fix this, and this appears to work in general, but I'm missing context on why asdf needs to resolve symlinks at all?

Would it not be simpler to let the filesystem do the work, using a symlink path in https://github.com/asdf-vm/asdf/blob/master/lib/commands/version_commands.sh#L40-L45?

As a workaround I was able to set ASDF_DEFAULT_TOOL_VERSIONS_FILENAME to the version in my dot-file directory and it now works as expected.

I also worked on a patch for this and my solution was similar to @craigfurman. The documentation for GNU stow says:

A relative symlink names a relative path; that is, one not starting from /. The target of a relative symlink is computed starting from the symlink鈥檚 own directory. Stow only creates relative symlinks.

Seems like we need to dirname the symlink and prepend that to the directory the symlink points to as opposed to PWD. When looking to see what POSIX says about this all I could find was that

If the pathname does not begin with a slash, the predecessor of the first filename of the pathname shall be taken to be the current working directory of the process (such pathnames are referred to as "relative pathnames").

I'm not sure if this is an macOS issue, asdf, or something else.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

michalmuskala picture michalmuskala  路  5Comments

romenigld picture romenigld  路  4Comments

pachun picture pachun  路  3Comments

peleteiro picture peleteiro  路  3Comments

dmlemos picture dmlemos  路  3Comments