Installing OpenNMS and had a bit of a snag. Issue resolved but it left me wondering...

Why doesn't this work:

[nac@localhost /]$ cd opt/opennms/bin/
[nac@localhost bin]$ runjava -s
-bash: runjava: command not found

...but this does:

[nac@localhost /]$ opt/opennms/bin/runjava -s
runjava: Looking for an appropriate JRE...
runjava: Checking for an appropriate JRE in JAVA_HOME...
runjava: skipping... JAVA_HOME not set
runjava: Checking JRE in user's path: "/usr/bin/java"...
runjava: found an appropriate JRE in user's path: "/usr/bin/java"

I'm using cygwin. ssh into a fedora box. the output is green for ls /opt/opennms/bin if that helps...


2 Answers 2


Your $PATH does not contain the current directory, .. Therefore, the runjava executable is not found when you try to execute it without a path while located in its directory.

It also does not contain /opt/opennms/bin. If it had done, typing runjava (while in any directory) would have located the executable there.

A few solutions:

  1. Always use the path to the executable, either /opt/opennms/bin/runjava, or ./runjava if you are within the /opt/opennms/bin directory.
  2. Add /opt/opennms/bin to your path. To do this, edit your shell initialization file (.bash_profile or .bashrc for bash) and add the line


    Then restart the Cygwin session.

  3. Create an alias:

    alias runjava=/opt/opennms/runjava

    This would be added to a shell startup file. This will run the runjava executable as if you had typed the complete path to it when you give the command runjava.

You do not want to add . to the PATH variable. For a discussion about that, see the question "Is it safe to add . to my PATH? How come?"

  • This is probably not a good idea. I think that directory contains a bunch of generic and conflicting stuff you don't want in PATH. E.g., issues.opennms.org/browse/NMS-9102 suggests it contains an install command.
    – derobert
    Sep 22, 2017 at 16:45
  • @derobert Having it last in the path will make sure that install is picked up from a proper place if needed. The OpenNMS install would very likely have to be run with a complete path.
    – Kusalananda
    Sep 22, 2017 at 16:47
  • 1
    I think having conflicting names in $PATH is generally a bad idea, unless you're explicitly intending to override one (e.g., by putting it first). Its reasonably unlikely that install is missing from the system paths, but if it were then some interesting errors (or worse) would result when a makefile winds up running OpenNMS's install command by mistake. And I wonder how many other potential issues like that exist in said directory; I couldn't find a file listing online.
    – derobert
    Sep 22, 2017 at 16:57
  • 1
    @derobert An alias may be a good solution then...
    – Kusalananda
    Sep 22, 2017 at 17:01
  • @derobert Coming back to an old thread... Also note that some systems on purpose put different utilities with the same name in $PATH (e.g. Solaris). The composition of $PATH then picks what "personality" the current shell session has.
    – Kusalananda
    Mar 31, 2019 at 9:29

Because . is not part of your $PATH. Unix will only search for executable programs in those directories listed in $PATH.

Further, having . in $PATH is a security risk, so don't do that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .