The uutils/coreutils implementation of readlink emits error messages to
stderr when invoked on non-symlinks (regular files or directories):
readlink: <file>: Invalid argument
By contrast, BSD and GNU readlink fail silently. This caused unwanted
error output when using jenv with uutils/coreutils.
The resolve_link() function is used in abs_dirname() to traverse paths,
and may be called on non-symlinks during normal operation. This fix adds
a symlink check using [ -L "$1" ] before invoking readlink, which:
- Prevents spurious error messages from uutils readlink
- Maintains compatibility with BSD, GNU, and uutils implementations
- Preserves real error visibility by only calling readlink on symlinks
- Avoids the need to suppress stderr which would hide genuine errors
This seems like the reason for the jenv-shim being left behind i.e.
rehash is run, the shim is created but we can't redirect to stderr
because of noclobber. This causes rehash to exit because of set -e but
does so before the trap is established to clean up the shim. Further
rehash executions fail because of the existence of the shim.
See https://github.com/rbenv/rbenv/issues/759#issuecomment-289326891
This adds new command to jenv: `jenv with <version> <command...>`.
It executes the command with the specified version being effective.
It's roughly equivalent to invoking `jenv shell <version>` and then
`<command>` except that it doesn't change the state of running shell.
Alternative could be to invoke `jenv shell` in a subshell, like
( jenv shell <version>; <command>; )
except that this actually doesn't work, because the version set by `jenv
shell` becomes effective only after `_jenv_export_hook` executes, which
in turn happens only when the prompt is printed.
The other alternative is to set the JAVA_HOME explicitly
JAVA_HOME=~/.jenv/versions/<version> <command>
This works, but is arguably verbose.
Summary of changes
- remove exports. The script is invoked as a subprocess, not sourced.
It's role is to print to stdout the path to JVM home
- as an intentional side effect of removing export, `jenv-javahome` now
exits with non-zero status when `jenv-version-name` fails
- remove invocation of `jenv-options` as the result was unused