UNIX for Dummies Questions & Answers

"Doesn't work" isn't helpful... Please tell us exactly what you did and exactly what happened.

If gromacs was compiled for local installation, it should know what folders to look in one hopes, once you get your PATH sorted out.

I'm sorry about that.

I did exactly what bartus11 suggested, specifying the full path for the local install, however when I ran a simulation the program didn't run from the local install but from the main one.

However, in gromacs I need two things: the executable tools and the directory that contains all the forcefield files. These two are in different directories in the local install. I think I should add two lines in the profile; one which will point to all the executables and another one which will point to the forcefield files and so on.

I will post an update when I try it.

[Or I could also try this:

4.11. Getting access to GROMACS after installation

GROMACS installs the script GMXRC in the bin subdirectory of the installation directory (e.g. /usr/local/gromacs/bin/GMXRC), which you should source from your shell:

$ source your-installation-prefix-here/bin/GMXRC

It will detect what kind of shell you are running and set up your environment for using GROMACS. You may wish to arrange for your login scripts to do this automatically; please search the web for instructions on how to do this for your shell.

Many of the GROMACS programs rely on data installed in our share/gromacs directory. By default, the programs will use the environment variables set in the GMXRC script, and if this is not available they will try to guess the path based on their own location. This usually works well unless you change the names of directories inside the install tree. If you still need to do that, you might want to recompile with the new install location properly set, or edit the GMXRC script.

(I'm only writing this down just in case anyone else is having the same problem)]

Kind regards
Athina

Wouldnt symlinking the executables to /bin make it easier to execute them?

yes, definitely. You may also post the content of this GMXRC script so that we can suggest some course of action.

Let me address some problem you seem to have in understanding how UNIX works:

To execute an executable file you specify the full path to it:

Code:

/path/to/some/executabe/file

Note, that for executables there is no "default" path, which is quite unlike in Windows: in DOS or the Windows shell if you happen to be in directory \some\where and you type "program" without specifying anything the file \some\where\program.exe would be executed. Not so in any UNIX. In UNIX you would have to write ./program ("." in this case means "current directory") to force the execution of a program in the current directory.

Because this is cumbersome (and - like you - nobody wants to type that much every time) there are few devices to cut short the effort: the first one is the PATH variable. This is a list of directories which are searched for the executable if no path is specified. The directories to search are separated by ":". You can display the current value of your PATH variable by entering the following, with a similar result as shown here:

Code:

# echo $PATH
/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/bakunin/bin:/usr/bin/X11:/sbin:/usr/local/bin:/usr/local/sbin:/home/bakunin/bin

This list of pathes are searched from the beginning. If i type prog and there is a file /etc/prog and another /sbin/prog the first one would be executed, because "/etc" comes before "/sbin" in my PATH. To make sure your local program becomes executed instead of the main one, add the path to it at the beginning of the PATH variable, like this:

Code:

# echo $PATH
/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/athina/bin
# PATH="/path/to/local/gromacs:$PATH"
# echo $PATH
/path/to/local/gromacs:/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/athina/bin

A second device for shortening the typing i already used above: "." is always the current directory and if you are in the right directory you simply type "./prog" to execute an executable named "prog" which is there. It is even possible to add "." to the PATH, which makes UNIX behave like Windows in this regard. You should NOT DO THIS, though, because it poses security hazards. I just mentioned it because most users come up with that, thinking that it would be a great idea. It is not.

There are other "macros" for certain directories too: ".." is the directory above the current one. if you are in "/some/where", ".." would point to "/some". "~" is always set to your home directory (usually "/home/<username>"). "~<username>" points to the home directory of the user named "username". You can use these symbols in your PATH and in any other environment variables too.

Note that PATH is modifiable like any other environment variable. Execute

Code:

VARIABLE="some value"

to set VARIABLE to "some value". Always use double quotes and do NOT surround the equals sign with spaces. To display the current value of VARIABLE do (notice the dollar sign):

Code:

echo $VARIABLE

As UNIX is case sensitive, do not confuse upper- and lowercase:

Code:

VAR="this"
var="that"
echo VAR is $VAR but var is $var

I hope this helps.

bakunin