-1

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...

Johnny
  • 5
  • Possible duplicate of: https://stackoverflow.com/questions/6331075/why-do-you-need-dot-slash-before-script-name-to-run-it-in-bash – jesse_b Sep 22 '17 at 16:03
  • @Jesse_b you can't have duplicates across sites. – derobert Sep 22 '17 at 16:29
  • 2
    Possible duplicate of Is it safe to add . to my PATH? How come? – derobert Sep 22 '17 at 16:31
  • It's because . (current directory) is not a path the shell looks for executables in; https://unix.stackexchange.com/questions/65700/is-it-safe-to-add-to-my-path-how-come explains why. – derobert Sep 22 '17 at 16:32
  • @derobert No it's not. The solution does not necessarily involve adding . to $PATH. – Kusalananda Sep 22 '17 at 16:32
  • @Kusalananda I understood OP's question as why runjava from the directory it's in doesn't work (presumably compared to Windows/DOS where it does work). . not being in the path is the reason. That question explains why . is not in the path. – derobert Sep 22 '17 at 16:34
  • @derobert But it doesn't give an answer to the OPs issue... It just explains why the obvious solution is a bad one. – Kusalananda Sep 22 '17 at 16:41
  • 1
    @Kusalananda I see that reading is possible, now that you've pointed it out. I didn't read it as the OP wanting to change the behavior, just understand why it was different than what he's used to (the DOS/Windows behavior) – derobert Sep 22 '17 at 16:43

2 Answers2

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

    PATH="$PATH:/opt/opennms/bin"

    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?"

Kusalananda
  • 333,661
  • 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., https://issues.opennms.org/browse/NMS-9102 suggests it contains an install command. – derobert Sep 22 '17 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 '17 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 '17 at 16:57
  • 1
    @derobert An alias may be a good solution then... – Kusalananda Sep 22 '17 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 '19 at 09:29
1

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.

hymie
  • 1,710