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
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)
Keep JDK_HOME environment variable in sync with JAVA_HOME to avoid discrepancies within the same (i.e. not new or reloaded) shell whenever `jenv init -` is being executed.
Shell detection using $SHELL variable breaks in the case of
for example X sessions which are started with bash when the user
has a different shell session set. The fix applies the rbenv
code for shell detection which is more exhaustive.