I could not find a simpler way to do this; suggestions welcome!

How about the solution I suggested wherebin/rbenv is changed to a calling script instead?

readlink=$(type -p greadlink readlink 2>/dev/null | head -n1)

Can be changed toreadlink=$(type -P readlink) || readlink=$(type -P greadlink) avoiding the use of
head and a pipe which likely summons another subshell.

resolved="$($readlink "$rbenv_bin" 2>/dev/null)"

$readlink here might be worth quoting.

libexec_dir andRBENV_ROOT might also be worth converting to their canonical paths since they are being compared.

Excellent suggestions; thank you!

How about the solution I suggested wherebin/rbenv is changed to a calling script instead?

That is also valid and I experimented with changing thebin/rbenv that ships with rbenv to be a script instead of a symlink tolibexec/rbenv. However, for backwards compatibility with other rbenv setups that may be using symlinks already, I thought it would be a nice touch thatlibexec/rbenv goes back to resolving symlinks, and if it has that ability, then I would rather keepbin/rbenv as a symlink.

Master version is working again thank you. Just a minor thing to consider: Ifgreadlink orreadlink exists as an exported function,type -p will print nothing but still return 0 exit status.type -P otoh will only return 0 if executable is found in path. Is there a reason whytype -p is preferred?

Ah, I didn't know that; thanks for explaining the distinction.

I have been usingtype -p for testing support for executables in all my bash scripts for years, and never have I encountered a bug report with that. I did not even know abouttype -P. I don't feel strongly enough about fixing this right now, so let's see if we can get away with this. If someone exports a function calledreadlink from bash, I hope that they make that function behave like readlink.

Ah, only now I understand what you were saying: if someone did export a function calledgreadlink, the result will be an empty string. I will quickly fix this; thanks!