I want to make a script starting with a line:
#!java hogehoge.Hoge
In my machines of OS X and CentOS7, it runs.
But machines of CentOS6 give me an error:
./test.sh: bad interpreter: java
(My OS is JP so I omitted some of error messages but anyway it says java does not exist.)
All the environments are under zsh and
of course, every $PATH contains a certain PATH like /usr/bin.
If I try a new script starting with:
#!/usr/bin/java hoge.Hoge
then it runs even in where the script with "java" does not work.
Does the difference come from the one between OSs?
or is there anything else that I do not realize?
Java isn't a script interpreter, but you can run your java process with a script. Something like
#!/usr/bin/env bash
# export JAVA_HOME="/path/to/java_installation"
# export PATH="$PATH:$JAVA_HOME/bin"
java hoge.Hoge
You may need to define JAVA_HOME and add it to your PATH (depending on your installation of Java).
Related
I am trying to setup ANTLR4 and I am having issues setting the classpath.
I followed the instructions in the book "The Definitive ANTLR 4 Reference 2nd Edition", in section "Installing ANTLR", also I followed the instructions here and I have not got any results running in command line antlr4 or grun (the alias created).
I am running on a MacbookPro M1, Monterrey. I tried this with java 11 and 8 and the results were the same. I use sdkman to handle multiple java versions. Also my default terminal is oh-my-zsh.
In my bash_profile I added ANTLR configurations like this:
and in file zshrc I am loading configuration from bash_profile.
This is the output from my terminal.
Mac OS is gradually locking things down tighter and tighter on the system volume. While I think there's a good argument that /usr/local/ shouldn't be a part of that, it looks like it is.
Try placing your antler jar file some place within you home directory (perhaps changing all references to /usr/local to just be ~ (or maybe ~/local if you'd prefer to separate them out.)
I just downloaded the latest:
cd ~/lib
sudo curl -O https://www.antlr.org/download/antlr-4.11.1-complete.jar
changed by .zshrc to reference the new version:
export CLASSPATH=".:$HOME/lib/antlr-4.11.1-complete.jar:$CLASSPATH"
alias antlr4='java -jar $HOME/lib/antlr-4.11.1-complete.jar'
alias grun='java org.antlr.v4.gui.TestRig'
grun is running just fine
I had SunOs 5.10 unix server , where i had written a script to execute a java file which is as below
#!/bin/ksh -x
export JAVA_HOME=openjdk1.8.0_331/bin
$JAVA_HOME/java com.myclass.MyClient
in this script there is alot of code which includes log file, and other binaries class path added before exporting JAVA HOME. But when i am executing i am getting the below error
openjdk1.8.0_331/bin/java : Cannot execute
i had changes lot of java versions but getting the same error
Your JAVA_HOME is not an absolute path. This is broken; many tools will just fail when you do this. Just make it an absolute path. It may or may not explain your error, but it's a ticking timebomb.
JAVA_HOME cannot be bin; its the level above bin.
It looks like you're using JAVA_HOME as an ersatz script variable to make your script work, but this is wrong: JAVA_HOME is used by all sorts of tools and has a very specific meaning, and it's not whatever you think it is.
There are 2 obvious explanations for your error:
Some tool sees JAVA_HOME, attempts to run java based on this, and fails, because your JAVA_HOME is broken. There's a ton of infra that is 'custom' per OS, and it may well be that the SunOS setup didn't fail if you set JAVA_HOME to broken values, but it does fail here. The fix is to not have broken JAVA_HOME, not to start looking for a setup on your new OS that can deal with broken JAVA_HOME settings. In other words, your script was always broken, it just so happens that your specific set up on that specific server on that specific version of sun OS so happened to be capable of dealing with the mess.
A much simpler explanation is also possible: That executable does not run on your OS+Architecture combination. trivially testable: Do NOT set JAVA_HOME at all and just try to run that java executable by e.g. cd ing to the path and running ./java -version. See what happens. If that also gives you cannot execute, voila - the script isn't the problem (though it still has a broken JAVA_HOME you should be fixing), you need to install a JVM that works on your OS+Architecture.
I downloaded SymmetricDS, a tool for Database replication and tried to run it on my Windows7 machine. The program can be launched from command line and it works with Windows Terminal. However I always prefer Git Bash for command line stuff. When I run command sym though, I got error:
Error: Could not find or load main class org.jumpmind.symmetric.SymmetricLauncher
This tool is written in Java. I have JDK 1.8 installed. Git Bash inherits all environmental variables including $PATH and $JAVA_HOME from Windows. But why is it complaining about not finding the class?
The sym command is really running the following command:
exec "$SYM_JAVA" $SYM_OPTIONS -cp "$CLASSPATH" org.jumpmind.symmetric.SymmetricLauncher "$#"
All the jars are located in lib under the root directory of the application. The classpath is defined in a sym.service.conf inside conf directory:
# Java Classpath
wrapper.java.classpath.1=patches
wrapper.java.classpath.2=patches/*
wrapper.java.classpath.3=lib/*.jar
wrapper.java.classpath.4=web/WEB-INF/lib/*.jar
# Application main class and arguments
wrapper.app.parameter.1=org.jumpmind.symmetric.SymmetricLauncher
I added echo $CLASSPATH right before the exec to print out the class path and it did seem to get all of them right:
/c/Users/dnj0109/Apps/symmetric-server-3.8.29/patches:
/c/Users/dnj0109/Apps/symmetric-server-3.8.29/patches/*:
/c/Users/dnj0109/Apps/symmetric-server-3.8.29/lib/*:
/c/Users/dnj0109/Apps/symmetric-server-3.8.29/web/WEB-INF/lib/*
That could be related to this thread:
On Windows, the path separator is a semicolon (';' instead of ':').
Don't ask why. Traditionally, the semicolon is interpreted by the Bash as
the command separator, so you'll have to escape it:
$ java -cp lib/clojure-1.1.0.jar\;lib/clojure-contrib-1.1.0.jar
If you wonder why it works with PATH: MSys has special handling routines
for that.
Another reason that a java app may run in a Windows CMD shell but not in a Windows git bash shell is that the classpath used to run the app contains one of the following:
relative paths (e.g. ../foo)
network drives (e.g. //servername/bah
See:
https://github.com/git-for-windows/git/issues/1028
I want to use an environment variable as a JVM option when executing java -jar.
The command I want to execute it:
java -XX:onOutOfMemory='echo test' -jar foo.jar
When I run the above command as is, the jar will run.
(If you don't have the foo.jar, you will get an Error: Unable to access jarfile foo.jar error. But this still means that the option gets used correctly).
But when I create an environment variable containing the JVM option, and run the command using that variable.
OOM="-XX:onOutOfMemory='echo test'"
java $OOM -jar foo.jar
Than I get the following error:
Error: Could not find or load main class test'
It seems like the java command is ignoring the quotes around 'echo test'.
After looking for similar questions on SO and on other websites, I tried various variations of using quotes:
OOM="-XX:OnOutOfMemoryError=\"echo test\""
OOM='-XX:OnOutOfMemoryError="echo test"'
OOM=-XX:OnOutOfMemoryError="echo test"
But they all result in the same error.
An article from Oracle concerning JVM options, mentions using a semicolon:
-XX:OnOutOfMemoryError="<cmd args>; <cmd args>"
But the purpose of the semicolon is to separate multiple commands, not command and arguments. So this does not fix my problem.
Does anybody know how I can correctly move the -XX:onOutOfMemory='echo test' option into an environment variable?
When running java, you should quote $OOM
Example:
java "$OOM" -jar foo.jar
See Why does my shell script choke on whitespace or other special characters? on Unix stackexchange for why this is needed.
I have a program which allows me to define the java executable (/usr/bin/java), but does not allow me to add specific arguments to the executable.
I want to be able to run Java with a specific argument each time in order to enable Security Manager.
So far, I have tried to add the argument after /usr/bin/java, so it looks like
java=/usr/bin/java -Djava.security.manager -Djava.security.policy=/home/java.policy
That did not work as the program probably checks to see if a file exists. Another way I tried was to make a bash script called java which contained:
/usr/bin/java -Djava.security.manager -Djava.security.policy=/home/java.policy $*
I then set the java path to /home/java (Location of my script). That however did not work either. Is there some sort of way I can do this?
Thanks.
Put your java call in a shell script java.sh:
#!/bin/bash
/usr/bin/java -Djava.security.manager -Djava.security.policy=/home/java.policy $#
Change permissions with chmod u+x java.sh, then call your program with java=./java.sh (adapt path for your script as needed).
Notes about executable bit and shebang line
Both the shebang line (#!/bin/bash) and execute permission are important here. Without them, system calls of the exec* family will fail because the kernel does not know what to do with the file or because execution is rejected due to the missing executable bit.
This is different when run directly from a shell (./java.sh), because most shells have some compatibility feature for that case so they will run a script in a shell if exec* fails. The execute permission must be set though.
The only case where neither is needed is if you give your script as argument to the shell: bash java.sh.
Your second approach would be ok, but your problem is likely to be that your Multicraft application is not finding your script. More so, it's the environment of your web server (Apache?) that may need to have PATH altered to be able to find your java wrapper script.