executing unix code from the terminal

Question

I have a directory on my hard drive that contains a collection of Unix executable files that I am trying to run from the terminal. When I browse the directory from the terminal it shows all the files are there but when I enter the name of one of the Unix executables it says '-bash orca: command not found'(the executable is called 'orca'). If I browse to the folder in the finder and click on that same file, a terminal window appears and runs the file. However, because the program requires that I specify an input file, I get the following returned:

/Users/damonrobles/Documents/orca_macosx_r2360/orca ; exit;
Damon-Robless-MacBook-Pro:~ damonrobles$ /Users/damonrobles/Documents/orca_macosx_r2360/orca ; exit;
This program requires the name of a parameterfile as argument
For example ORCA TEST.INP 
logout

[Process completed]

According to the program manual, I should call the program from the terminal as follows:

nohup orca Inputfile.inp >& outputfile.out

but when I do this it simply generates an output file that says:

nohup: orca: No such file or directory 

and returns me to the terminal prompt. I can't figure out what the heck the problem is, although I am a novice terminal user so I'm sure it's something dumb on my part. Any help is greatly appreciated! I'm on a MacBook Pro, running OSX 10.6.8.

Solution 1

You'll want to use ./orca instead of just orca. In OS X, the current directory (.) isn't in $PATH by default, so you can't execute programs in the current directory without explicitly naming it.

Solution 2

One option is to add

/Users/damonrobles/Documents/orca_macosx_r2360

to your PATH environment variable, if you are going to leave the code installed under your Documents directory.

Another option you can consider is to add '.' to your PATH.

Although it can be dangerous (to add '.' to PATH), I work in sufficiently clean environments that I have '.' at the front of my PATH. That is more dangerous than having it at the back of PATH, and both of these are more dangerous than not having '.' on your PATH.

The advantage of having '.' at the front is that while developing a program, I don't have to specify ./program to run the local copy instead of the installed copy. The disadvantage of having '.' at the front is that if someone gets onto my machine and creates a Trojan Horse called 'ls' (say) in one of my directories and I run 'ls' in that directory, I run their Trojan Horse instead of the real version. If they've got any sense, the Trojan will clean up behind itself and run the intended command, meaning I might not notice. It is up to you whether you consider that a serious risk or not. Adding '.' at the end of PATH means that you'll run programs in the current directory that have no analogue anywhere else in your PATH; however, if you have an installed version of the program in, say, /usr/local/bin (and that is on your PATH), then the installed version will be run in preference to the local version. That may or may not matter to you; it does to me so I put the '.' at the front, but it is a considered and understood risk.

YMMV; be cautious.

Solution 3

Just to expand on @jtbandes answer: you can (1) navigate to the directory containing orca (as you say) and do as he says, you can (2) use a full path to the executable like /Users/Damon/foo/bar/orca (or to the input file for that matter), or you can "link" the executable to a directory that's on your $PATH. For instance, if orca was on the Desktop, you could do:

mkdir bin
PATH=$PATH:~/bin;  export PATH
echo $PATH
ln -s ~/Desktop/orca ~/bin
ls -al ~/bin
orca infile > outfile

To make this permanent, you would alter .bash_profile in your home directory.

Comments

[Tom Zych]

@Damon Robles: If you're thinking you can just add . to $PATH, that can be done but it's a security risk; it makes it easier for people to fool you into executing their malicious program instead of the standard one. So don't.

[Assembler]

@Tom Zych: I'd never considered the security risk of doing that. Thanks for pointing it out.

[Admin]

always have a well-prepared sl binary in your homedir, you never know who might run it one day...

[Assembler]

@mvds +2 if I could :D

[Wooble]

If you're not on a shared machine, the risk is pretty much 0; to get a malicious executable onto your machine the attacker will have to already have completely pwned you.

[Tom Zych]

@Wooble - What if you run a malicious script in your browser? It'll run with your permissions and can write files to your home directory tree.

[Wooble]

@Tom: browsers generally sandbox javascript so it can't write to the filesystem.