fix: Allow path: versions to use ~

[hyperupcall]

Summary

$ asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git
$ asdf install elixir 1.10.2
$ asdf local elixir path:~/.asdf/installs/elixir/1.10.2/
$ cat .tool-versions
elixir path:~/.asdf/installs/elixir/1.10.2/
$ command -v elixir
/home/edwin/.asdf/shims/elixir

Closes: #941

Other Information

The lib/functions/versions.bash change is due to a bug that apparently didn't show up before (from this):

asdf local elixir path:~/.asdf/installs/elixir/1.10.2/
tail: cannot open '/tmp/tmp.OU7v1JCUaV/.tool-versions' for reading: No such file or directory

[Stratus3D]

Why doesn't util_resolve_user_path print the resolved path directly? If it did we could simplify this to:

printf "%s\n" "$(util_resolve_user_path "${version_info[1]}")"

[Stratus3D]

@hyperupcall based on your latest comment, could this be changed to:

util_resolve_user_path "${version_info[1]}"
printf "%s\n" "${REPLY}"

I'd also prefer the REPLY variable be named something more specific, so as to better indicate it's origin. In this case, what about $util_resolve_user_path_reply?

util_resolve_user_path "${version_info[1]}"
printf "%s\n" "${util_resolve_user_path_reply}"

[hyperupcall]

I feel very strongly towards REPLY - I did change it to util_resolve_user_path_reply though

[Stratus3D]

Not sure about the REPLY variable. If we do want to use a variable I think it should have a more unique name, for example, util_resolve_user_path_reply.

[hyperupcall]

@Stratus3D I remember seing your post on ASDF performance measurements, and my takeaway was that performance in ASDF could be better for reshim, but also just in general. And I found the REPLY pattern to be extremely useful to preserve the performance in all of my Bash scripts, and I thought it would be useful here too.

It obviates the spawning of extraneous subshells, which in my experience solves the death by a thousand paper cuts that Bash performance usually boils down to (if you have different experience, I'd like to hear it!). The only downsides that I've come across is that you have to write the unset -v REPLY; REPLY= boilerplate, and that for extremely large functions, you may have to name REPLY variable to something else, or move the REPLY= stuff to the end of the function (depending on how you write it). If you wish, I've written more about REPLY here (it's a little out of date, but its correct enough).

But I do use it over named variables like the one you suggested because it is obvious what the return variable is (no need to check), since as you know Bash doesn't support returning actual values. It also matches the read and select builtins.

But for whatever reason, you don't like this pattern or it's not applicable as much here, then I can rewrite it to use the more traditional approach - what are your thoughts?

[Stratus3D]

@hyperupcall that all makes sense, I'm just wondering if REPLY is the best choice of name. It's a stylistic thing I guess.

[Stratus3D]

Looks like we encountered a schedule brownout for runners on Ubuntu 18.04. We'll need to address that at some point.

@hyperupcall did you see my PR comments above?

[hyperupcall]

@hyperupcall did you see my PR comments above?

Yup! Fixed the things

[Stratus3D]

This change could probably be reverted.

[hyperupcall]

Oops I don't think I intentionally removed that