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)
This commit updates `jenv-add` to handle version numbers which are > 1.8 and do not include a `.` _but may include a non-numeric suffix_. For example, this is the case when installing JDK15 on Ubuntu 20.04 LTS from the Canonical PPA. In this case the version number parsed by `jenv` is `15-ea` ("ea" is for early adopter I believe).
The old `jenv` logic would only parse a single alias for this JRE, the full string `15-ea`. This is especially undesirable since the `-ea` suffix is likely to go away in the near future, either via PPA updates or distro updates.
This commit updates the `sed` call which parses `JAVA_SHORTESTVERSION` to look for an _optional_ `.`, rather than a required one.
For example,
```shell
$ sed 's/\([0-9]\+\).*/\1/' <<< 15-ea
15
```
This change _should_ not change other existing parsing behavior, e.g.
```shell
$ sed 's/\([0-9]\+\).*/\1/' <<< '1.8.0'
1
```
```shell
$ sed 's/\([0-9]\+\).*/\1/' <<< '14.0.1'
14
```
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.
Not sure if the front page, the readme file in master, or the JENV website is the best place to update the link to, but I believe this is the best option.
`GraalVM` includes `OpenJDK` in it's `java -version` output:
```
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-20190420112649.buildslave.jdk8u-src-tar--b03)
OpenJDK GraalVM CE 19.0.0 (build 25.212-b03-jvmci-19-b01, mixed mode)
```
so it needs to be an earlier check to get picked up correctly so it isn't incorrectly set to `openjdk`.
Additionally, added detection for Amazon Corretto which outputs `java -version` as:
```
openjdk version "1.8.0_212"
OpenJDK Runtime Environment Corretto-8.212.04.2 (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM Corretto-8.212.04.2 (build 25.212-b04, mixed mode)
```