We Keep Coding

How to set environment variables so they work in non-interactive bash shells?

I am running the amazonlinux:2 docker image directly from dockerhub and installing the corretto-17 JDK with the following command:
yum install -y git java-17-amazon-corretto-devel
Note: I am not using a custom Dockerfile, I do not control it and I can't change it.
When I then try and run my .gradlew task, it fails because there's no JAVA_HOME set.
So I do that by:
echo "export JAVA_HOME='/usr/lib/jvm/java-17-amazon-corretto.x86_64'" >> /root/.bashrc
If I manually connect a terminal to to the container, the .bashrc works fine and gradlew will run.
But when I run commands from outside the container via something like:
docker exec kopibuild /bin/bash -c "cd the-project-code && ./gradlew build"
The .bashrc is not loaded so JAVA_HOME is not set and gradlew fails.
My workaround is to add the interactive flag -i to the bash command and then it all works, but there are warnings in the logs about "cannot set terminal process group (-1): Inappropriate ioctl for device".
docker exec kopibuild /bin/bash -c "cd the-project-code && BASH_ENV=/root/.bashrc ./gradlew build"
But it didn't seem to do anything.
What's the right way to set environment variables for Amazon Linux so they will exist in non-interactive shell invocations?

After digging around on the Googles - I believe there is no standard Linux way to set an environment variable for non-interactive shells.
But there is a Docker way to answer the question. On the original docker create of the container from the amazonlinux:2 image, specify the environment variable via -e JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto.x86_64. This stores the environment variable in the docker metadata for the container and it will be available in all execution contexts, including non-interactive shells invoked directly via docker exec (without having to specify it explicitly for every exec command).
As far as I know, this is the same as what the ENV command in a Dockerfile does.

Make export JAVA_HOME=`/usr/libexec/java_home -v 1.8` permanent

I making an App whit JHipster I have two java SDK 14 and 8
every time I need to run JHpster I have to do in the terminal
export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
i want to make it permanent for this folder
im on macOS Catalina

In Linux, edit file "~/.bashrc", add the export command in that.
echo 'export JAVA_HOME=`/usr/libexec/java_home -v 1.8`' >> ~/.bashrc
Then, on a new shell, you should be able to see the variable exported. If you want to use the variable in your current GNOME/KDE session, you will need to logout/login again.
Either that or you will need to create a script to launch your application/compiler.

UBUNTU 13.04 GNOME_DESKTOP_SESSION_ID

A recent upgrade to SQL Developer 4.0 in Ubuntu 13.04 has generated an error.
gnome_desktop_session_id=this-is-deprecated
my current work around is to just run
$ unset gnome_desktop_session_id
After this I can run sql developer and everything works fine.
Any suggestions on how to fix this with out having to run the unset command every time?

I modified /opt/sqldeveloper/sqldeveloper.sh:
#!/bin/bash
unset GNOME_DESKTOP_SESSION_ID
cd "`dirname $0`"/sqldeveloper/bin && bash sqldeveloper $*

You can make your system set it for you by putting this unset command to /etc/profile or in a .sh shell script that you place in /etc/profile.d/
If you launch SQL developper from console, you can also put the command in .bashrc

SSH command can not start remote java process

I have a start function, and I put it in a script resides on a remote site, the function's code shows below.
function start() {
cd $install_dir
mkdir -p logs
export classpath=$classpath:$target_jar
nohup java -Xms2048m -Xmx8192m -server -XX:PermSize=128m -XX:MaxPermSize=256m \
-XX:+PrintGCDetails -XX:+PrintGCDateStamps \
-XX:-OmitStackTraceInFastThrow \
-cp $target_jar $main_class >> logs/jvm.log 2>&1 &
echo "Service started, see logs"
}
And when I try to call that function use ssh ssh xxx#host "./service.sh start", I can not start the java process, I only got the response message "Service started, see logs" and there's no error, the jvm.log is also empty. It apparently to me that my script has executed, but the target java process didn't run.
If I logon to that remote site, and execute ./service.sh start, it works.

Since you were able to run the service manually, the ssh and script part is fine.
What could go wrong is the environment. For example you referred java without absolute path. Hence your may be running a different version of it. It is also possible that variable for shared library loading (LD_LIBRARY_PATH) are having different values.
Finally check for file permissins

JAVA_HOME not found as Sudo

I have a bash script on a Linux box that runs a Jar file. When logged in as a regular user I don't have permission to run the script, but it prints the following log:
*INFO * Using JVM found at /opt/jdk6/bin/java
When I try to use the script with Sudo though, it gives:
*ERROR* Unable to locate java, please make sure java is installed and JAVA_HOME set
I've set JAVA_HOME to the same path above — can see it with echo $JAVA_HOME & it's also set as an option within the script. I'm happy that the script isn't the issue — it's a default CQ5 control script & I'm using it on dozens of other boxes without issue. Just unsure what I'm doing wrong above & presume it's something I'm missing re Linux set-up?
When I run the sudo command, does it have access to the JAVA_HOME that I set up as myself?

By default, sudo will cleanup the environment of the spawned commands. Pass -E to keep it:
sudo -E env
Compare to:
sudo env

"sudo -E " didn't solve the problem when JAVA_HOME was not exported. And when it was exported, "sudo " without -E works the same.
So you can add export JAVA_HOME=.../jdk<version> in your .bash_profile and .bashrc file.
In case you wondered what's the difference of .bash_profile and .bashrc, .bash_profile is executed upon login (e.g., show some diagnostic/welcome information). .bash_rc is executed when you open a new terminal (e.g., shift-ctrl-T).
In order to run some commands for both cases, you can put it in .bashrc file, and let .bash_profile source .bashrc:
if [ -f ~/.bashrc ]; then
source ~/.bashrc
fi

You could always just pass it to java explicitly like this:
sudo java -Djava.home=$JAVA_HOME Test