A short but unsuccessful script for calling a Java app.

[Stan Goodman]

I'm sure that this is not really on-topic for this group, but forums I
would have thought to be more appropriate yield unhelpful, inaccurate
or no repliies at all. Evidently, few groups are frequented by people
that understand both Java and Linux shell scripts.

I have written the following short script in SUSE Linux v9.3. I see
nothing wrong with either of its two lines, yet each line gets an
error message. I would be grateful if someone can tell me why. If
someone can also throw light on the reason that, despite the fact that
it is executable and that it contains the requisite first line, it
refuses to run; when I type its name (from the directory in which it
resides, I am informed that there is no such file. For the time being,
I run it as ". run", which works.

*****
#! /bin/bash
#
cd /home/stan/bin/genj
java -classpath ./lib/genj.jar genj.app.App

*****

Firstly, the cd line doesn't work at all. It gets an error message
saying "no such file or directory". There IS such a directory, and I
am running the script from it. Since this is an absolute directory
specification, it should leave me just where I am, and make no
complaint. But it doesn't matter what directory I specify, I get the
same error message.

The jave line gets an error message from the JVM, indicating that it
couldn't find class genj.app.App. I have used this application under
another OS, and know that this class is the entry point; the jar file
is where the script says it is, and this is its name. The lib
directory is, as it says, one directory down from the directory I am
in (and which the cd line was meant to bring me to if I had started
from some other directory). These two logether work in other OSes,
given only the obvious directory changes from system to system, and
turning "/" into "\". The JVM is v1.5.0_04.

What's wrong?

TIA

 

[Jon Haugsand]

* Stan Goodman

*****
#! /bin/bash
#
cd /home/stan/bin/genj
java -classpath ./lib/genj.jar genj.app.App

*****

Firstly, the cd line doesn't work at all. It gets an error message
saying "no such file or directory". There IS such a directory, and I
am running the script from it. Since this is an absolute directory
specification, it should leave me just where I am, and make no
complaint. But it doesn't matter what directory I specify, I get the
same error message.

Probably security switches configurated in /etc/httpd/conf/httpd.conf

The jave line gets an error message from the JVM, indicating that it
couldn't find class genj.app.App. I have used this application under
another OS, and know that this class is the entry point; the jar file
is where the script says it is, and this is its name. The lib
directory is, as it says, one directory down from the directory I am
in (and which the cd line was meant to bring me to if I had started
from some other directory). These two logether work in other OSes,
given only the obvious directory changes from system to system, and
turning "/" into "\". The JVM is v1.5.0_04.

Not surprising when you cannot change the directory.

 

[Rogan Dawes]

I'm sure that this is not really on-topic for this group, but forums I
would have thought to be more appropriate yield unhelpful, inaccurate
or no repliies at all. Evidently, few groups are frequented by people
that understand both Java and Linux shell scripts.

I have written the following short script in SUSE Linux v9.3. I see
nothing wrong with either of its two lines, yet each line gets an
error message. I would be grateful if someone can tell me why. If
someone can also throw light on the reason that, despite the fact that
it is executable and that it contains the requisite first line, it
refuses to run; when I type its name (from the directory in which it
resides, I am informed that there is no such file. For the time being,
I run it as ". run", which works.

OK, if it works when you do ". run", then your problem is one (or more)
of the following:

1. If you just try
$ run

and get "no such file or directory", it suggests that the current
directory is not in your path. This is the default for many Unixes, and
is a good thing!

Try calling it like

$ ./run

and see if it works.

If it does not work, it suggests that:

2. your shebang (#!) line is broken. To the best of my knowledge, there
should not be a space between the exclamation mark, and the first /.
Also, verify that /bin/bash indeed exists, and is executable.

*****
#! /bin/bash
#
cd /home/stan/bin/genj
java -classpath ./lib/genj.jar genj.app.App

*****

Firstly, the cd line doesn't work at all. It gets an error message
saying "no such file or directory".

How do you know that the first line generates the error? Does it even
execute the script, or is the error that it cannot find or execute the
script at all?

Rogan

 

[Rogan Dawes]

* Stan Goodman



Probably security switches configurated in /etc/httpd/conf/httpd.conf
or somewhere else. Look for the <Directory> directives.

Not sure where you saw anything about Apache in Stan's message?

 

[shakah]

I'm sure that this is not really on-topic for this group, but forums I
would have thought to be more appropriate yield unhelpful, inaccurate
or no repliies at all. Evidently, few groups are frequented by people
that understand both Java and Linux shell scripts.

I have written the following short script in SUSE Linux v9.3. I see
nothing wrong with either of its two lines, yet each line gets an
error message. I would be grateful if someone can tell me why. If
someone can also throw light on the reason that, despite the fact that
it is executable and that it contains the requisite first line, it
refuses to run; when I type its name (from the directory in which it
resides, I am informed that there is no such file. For the time being,
I run it as ". run", which works.

*****
#! /bin/bash
#
cd /home/stan/bin/genj
java -classpath ./lib/genj.jar genj.app.App

*****

Firstly, the cd line doesn't work at all. It gets an error message
saying "no such file or directory". There IS such a directory, and I
am running the script from it. Since this is an absolute directory
specification, it should leave me just where I am, and make no
complaint. But it doesn't matter what directory I specify, I get the
same error message.

The jave line gets an error message from the JVM, indicating that it
couldn't find class genj.app.App. I have used this application under
another OS, and know that this class is the entry point; the jar file
is where the script says it is, and this is its name. The lib
directory is, as it says, one directory down from the directory I am
in (and which the cd line was meant to bring me to if I had started
from some other directory). These two logether work in other OSes,
given only the obvious directory changes from system to system, and
turning "/" into "\". The JVM is v1.5.0_04.

What's wrong?

TIA

You probably don't want the extra space on the first line:
http://www.tldp.org/LDP/abs/html/sha-bang.html

If you don't have the cwd in your PATH you have to execute your script
with:
./run

Why bother with the cd?
#!/bin/bash
java -classpath /home/stan/bin/genj/lib/genj.jar genj.app.App

or, if you still have problems with that, maybe the following would
help with your debugging:
#!/bin/bash
GENJ_JARFILE="/home/stan/bin/genj/lib/genj.jar"
if [ -e "$GENJ_JARFILE" ] ; then
echo "jar file exists: $GENJ_JARFILE"
java -classpath "$GENJ_JARFILE" genj.app.App
else
echo "jar file does not exist: $GENJ_JARFILE"
fi

 

[Stan Goodman]

Not sure where you saw anything about Apache in Stan's message?

No Apache. No Wigwam.

 

[Stan Goodman]

Not sure where you saw anything about Apache in Stan's message?

 

[Stan Goodman]

OK, if it works when you do ". run", then your problem is one (or more)
of the following:

1. If you just try
$ run

and get "no such file or directory", it suggests that the current
directory is not in your path. This is the default for many Unixes, and
is a good thing!

I'm sure that the directory is not in the path, because I just made
it. I am surprised that it has to be in the path when I am running the
file from within the directory; I am coming from OS/2, where running a
file from within its directory doesn't require a path entry (because
there is nothing to seek). I'll get used to it. See below.

Try calling it like

$ ./run

and see if it works.

It doesn't. The error message is:

*****
: bad interpreter: no such file or directory
*****

Yet running it as <sh run> gets the error messages I have listed,
showing that the interpretor is NOT bad, the script is being run,
it doesn't understand the cd line, and it can't find the class that
I know to be there. The full message about the class, which I
have not given in full before, is:

*****
Exception in thread "main" java.lang.NoClassFoundError: genj/app/App
*****

Again, I know that this class is present in the jar, and that is its
correct name. I have used this application under OS/2, and the script
is a copy (with obvious changes) of the command file I have been using
with it for many years.

If it does not work, it suggests that:

2. your shebang (#!) line is broken. To the best of my knowledge, there
should not be a space between the exclamation mark, and the first /.
Also, verify that /bin/bash indeed exists, and is executable.

That's clear, because I can also run the script with <sh run> (sh is
an alias for bash).

The printed material that I have shows the space. But evidently it
doesn't matter, because it works the same with and without, and gets
the same error messages either way.

How do you know that the first line generates the error? Does it even
execute the script, or is the error that it cannot find or execute the
script at all?

I know the script is being executed because the error about the
genj.app.App comes from Java. When I comment that line out, so that
only the cd line remains, I get the error for it. When I comment out
the cd line, I get no error. Your question points up the fact that,
without going through the detective work, one would not know whether
the error message is talking about the script or the lines inside; I
don't think this speaks well for the interpreter, but [...].

 

[Stan Goodman]

You probably don't want the extra space on the first line:
http://www.tldp.org/LDP/abs/html/sha-bang.html

If you don't have the cwd in your PATH you have to execute your script
with:
./run

Why bother with the cd?

Because I am still feeling my way in Linux. If I find that I can start
such a script from the desktop without this line, I won't use it. I
put
it in because I need to establish ~/bin/genj as the working directory.

#!/bin/bash
java -classpath /home/stan/bin/genj/lib/genj.jar genj.app.App

or, if you still have problems with that, maybe the following would
help with your debugging:
#!/bin/bash
GENJ_JARFILE="/home/stan/bin/genj/lib/genj.jar"
if [ -e "$GENJ_JARFILE" ] ; then
echo "jar file exists: $GENJ_JARFILE"
java -classpath "$GENJ_JARFILE" genj.app.App
else
echo "jar file does not exist: $GENJ_JARFILE"
fi

Yes, I will run it, to prove which of the two entities it is that is
giving the line trouble.

Thank you.

 

[Gordon Beaton]

It doesn't. The error message is:

*****
: bad interpreter: no such file or directory
*****

Your file has windows line endings (CR LF) instead of unix line
endings (LF). Presumably you created the script using a windows editor
and transferred the file to your unix machine.

You can fix in in various ways, here are two:

- with the dos2unix utility:

dos2unix < run > run.tmp
mv run.tmp run

- with tr:

tr -d '\r' < run > run.tmp
mv run.tmp run

This will fix the other issues as well.

/gordon

 

[Monique Y. Mudama]

I'm sure that the directory is not in the path, because I just made
it. I am surprised that it has to be in the path when I am running
the file from within the directory; I am coming from OS/2, where
running a file from within its directory doesn't require a path
entry (because there is nothing to seek). I'll get used to it. See
below.

This is actually a security feature of sorts. What if you want to see
the contents of the current directory, and the current directory has
an executable named 'ls' that actually removes your home directory, or
similar?

If you really want the current directory to be in the path, you just
need to add . to the $PATH variable. But in practice all you need to
do is type ./my_executable instead of my_executable, which is only two
more letters and keeps you from accidentally running the wrong
executable. Well, sort of. It can't help it if you have two entries
in your PATH, both of which contain executables of the same name.

 

[Stan Goodman]

Your file has windows line endings (CR LF) instead of unix line
endings (LF). Presumably you created the script using a windows editor
and transferred the file to your unix machine.

No. I posted the messages to the NG from OS/2, which uses the same
two-byte EOL convention as Windows. The script itself was prepared in
Linux, with the kate editor, which I doubt can make files with
two-byte EOL. What you found can only be an artifact of the fact that
I am still setting up my Linux system (the script in question is a
part of that), and am able just now to post only from OS/2.

 

[Stan Goodman]

This is actually a security feature of sorts. What if you want to see
the contents of the current directory, and the current directory has
an executable named 'ls' that actually removes your home directory, or
similar?

If you really want the current directory to be in the path, you just
need to add . to the $PATH variable. But in practice all you need to
do is type ./my_executable instead of my_executable, which is only two
more letters and keeps you from accidentally running the wrong
executable. Well, sort of. It can't help it if you have two entries
in your PATH, both of which contain executables of the same name.

As you point out toward the end, one can't anticipate every possible
weird eventuality, and there is such a thing as running into
diminishing returns if one tries too hard to do so.

But it doesn't matter. I obviously accept that this is the convention,
and I will get used to it.

 

[Monique Y. Mudama]

As you point out toward the end, one can't anticipate every possible
weird eventuality, and there is such a thing as running into
diminishing returns if one tries too hard to do so.

Sure. I've just found it least confusing to use ./foo ... but as I
said, it's easy enough to change your $PATH to include the current
directory. Some sysadmins make this the default for their users,
actually.

But it doesn't matter. I obviously accept that this is the
convention, and I will get used to it.

Well, I'd say, understand why it's done this way, then decide if you
want to do things differently on your system. Configurability is one
of the great things about OSS and Unix-type systems.

 

[Stan Goodman]

Sure. I've just found it least confusing to use ./foo ... but as I
said, it's easy enough to change your $PATH to include the current
directory. Some sysadmins make this the default for their users,
actually.


Well, I'd say, understand why it's done this way, then decide if you
want to do things differently on your system. Configurability is one
of the great things about OSS and Unix-type systems.

Thanks for your comment.

Brevity apparently caused me to misspeak. I'll try to be more careful
and explicit:

Different OSes do things differently. Each OS can make rational
arguments for why it does things the way it does, but many of these
are, in the end, arbitrary. One becomes accustomed to the way one has
been doing things in the OS one has been using for many years; this is
called "habit". I, for example, have habits developed under OS/2 since
1992, some years before that under DOS, and before that under CP/M (I
have never used Windows, except to help my computer-illiterate
neighbors). Before CP/M, I used a machine that I built and for which I
programmed a rudimentary OS. When I moved from CP/M to DOS, there were
some habits that I had to break. For example the order of the source
and target in copy and rename commands. So there were things I had to
get used to. In the same way, I will get used to the way that Linux
does things. I can only hope for the indulgence of people more
experienced than me in the Linux community while I am becoming
accustomed to their way of doing things, and indeed to their ways of
thinking.