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
Prevents globbing of JENV_ROOT/plugins/* from resulting in the literal
string being used when no plugins are present in the folder. This was
causing jenv doctor to fail resulting in a non-zero exit code.
using `ps` to detect the shell fails in some cases (For me, it is using
a docker container to run an x86 OS image on an M1 Mac - the process is
is /usr/bin/qemu-x86_64 /bin/bash)
Using the $[SHELL]-VERSION environment variables is probably the most
fool-proof way to detect the shell.
using `ps` to detect the shell fails in some cases (For me, it is using
a docker container to run an x86 OS image on an M1 Mac - the process is
is /usr/bin/qemu-x86_64 /bin/bash)
Using the $[SHELL]-VERSION environment variables is probably the most
fool-proof way to detect the shell.
Right now, jenv init only partially runs if it can't detect the shell.
Since bash-derived shells are probably the most common, let's just
assume that it is bash-compatible.
(I ran into this running from a x86 Docker container on an M1 Mac, where we
currently detect the shell as qemu-x86)