1. Eclipse User Library Path
2. Mac User Library Path
3. User Library Path Mac
4. User Library Path Example
5. Qemu User Library Path

What are Environment Variables?

Environment variables are global system variables accessible by all the processes/users running under the Operating System (OS), such as Windows, macOS and Linux. Environment variables are useful to store system-wide values, for examples,

I install custom software in /usr/local/lib. How do I set the PATH and LDLIBRARYPATH in CentOS 6 system-wide to use /usr/local/lib. I realize there may be more than one way. Continuing with the build process: Setting PATH and LDLIBRARYPATH for the bash shell: What the distribution contains: Setting PATH and LDLIBRARYPATH for the tcsh shell. EDIT: LDLIBRARYPATH is for shared libraries that contain machine code. User contributions licensed under cc by-sa. Rev 2021.8.5.39930. Linux is a registered. User classes search path (in short, class path): determined in the following order: Defaulted to the current working directory (. Entries in the CLASSPATH environment variable, which overrides the default.

• PATH: the most frequently-used environment variable, which stores a list of directories to search for executable programs.
• OS: the operating system.
• COMPUTENAME, USERNAME: stores the computer and current user name.
• SystemRoot: the system root directory.
• (Windows) HOMEDRIVE, HOMEPATH: Current user's home directory.

(Windows) Environment Variables

Environment Variables in Windows are NOT case-sensitive (because the legacy DOS is NOT case-sensitive). They are typically named in uppercase, with words joined with underscore (_), e.g., JAVA_HOME.

Display Environment Variables and their Values

Eclipse User Library Path

To list ALL the environment variables and their values, start a CMD and issue the command 'set', as follows,

Try issuing a 'set' command on your system, and study the environment variables listed. Pay particular attention to the variable called PATH.

To display a particular variable, use command 'set varname', or 'echo %varname%':

Set/Unset/Change an Environment Variable for the 'Current' CMD Session

To set (or change) a environment variable, use command 'set varname=value'. There shall be no spaces before and after the '=' sign. To unset an environment variable, use 'set varname=', i.e., set it to an empty string.

For examples,

An environment variable set via the 'set' command under CMD is a local, available to the current CMD session only. Try setting a variable, re-start CMD and look for the variable.

Using an Environment Variable

To reference a variable in Windows, use %varname% (with prefix and suffix of '%'). For example, you can use the echo command to print the value of a variable in the form 'echo %varname%'.

How to Add or Change an Environment Variable 'Permanently'

To add/change an environment variable permanently in Windows (so that it is available to ALL the Windows' processes/users and stayed across boots):

1. Launch 'Control Panel'
2. 'System'
3. 'Advanced system settings'
4. Switch to 'Advanced' tab
5. 'Environment variables'
6. Choose 'System Variables' (for all users)
7. To add a new environment variable:
   1. Choose 'New'
   2. Enter the variable 'Name' and 'Value'. Instead of typing the 'value' and making typo error, I suggest that you use 'Browse Directory...' or 'Browse File...' button to retrieve the desired directory or file.
8. To change an existing environment variable:
   1. Choose 'Edit'
   2. Enter the new 'Value'. Instead of typing the 'value' and making typo error, I suggest that you use 'Browse Directory...' or 'Browse File...' button to retrieve the desired directory or file.

You need to RE-START CMD for the new setting to take effect!

To verify the new setting, launch CMD:

PATH Environment Variable in Windows

When you launch an executable program (with file extension of '.exe', '.bat' or '.com') from the CMD shell, Windows searches for the executable program in the current working directory, followed by all the directories listed in the PATH environment variable. If the program cannot be found in these directories, you will get the following error:

To list the current PATH, issue command:

How to Add a Directory to the PATH in Windows

To add a directory to the existing PATH in Windows:

1. Launch 'Control Panel'
2. 'System'
3. 'Advanced system settings'
4. Switch to 'Advanced' tab
5. 'Environment variables'
6. Under 'System Variables' (for all users), select 'Path'
7. 'Edit'
8. (For newer Windows 10) A table pops up showing the directories included in the current PATH setting ⇒ 'New' ⇒ 'Browse...' to select the desired directory to be added to the PATH (Don't type as you will make typo error!) ⇒ Click 'Move Up' repeatedly to move it to the top ⇒ 'OK' (Don't 'Cancel') ⇒ 'OK' ⇒ 'OK'.
9. (For older Windows) If you didn't see a pop-up table, it is time to change your computer.

You need to RE-START CMD for the new PATH setting to take effect!

To verify the new setting, launch CMD:

Notes:

• Windows searches the current directory (.) before searching the PATH entries. (Unixes/macOS does not search the current directory, unless you include it in the PATH explicitly.)
• Windows uses semicolon (;) as the path separator; while Unixes/macOS uses colon (:).
• If your directory name contains special characters such as space (strongly not recommended), enclosed it with double quotes.

(macOS/Linux) Environment Variables

Environment variables in macOS/Unixes are case-sensitive. Global environment variables (available to ALL processes) are named in uppercase, with words joined with underscore (_), e.g., JAVA_HOME. Local variables (available to the current process only) are in lowercase.

Using Environment Variables in Bash Shell

Most of the Unixes (Ubuntu/macOS) use the so-called Bash shell. Under bash shell:

• To list all the environment variables, use the command 'env' (or 'printenv'). You could also use 'set' to list all the variables, including all local variables.
• To reference a variable, use $varname, with a prefix '$' (Windows uses %varname%).
• To print the value of a particular variable, use the command 'echo $varname'.
• To set an environment variable, use the command 'export varname=value', which sets the variable and exports it to the global environment (available to other processes). Enclosed the value with double quotes if it contains spaces.
• To set a local variable, use the command 'varname=value' (or 'set varname=value'). Local variable is available within this process only.
• To unset a local variable, use command 'varname=', i.e., set to empty string (or 'unset varname').

How to Set an Environment Variable Permanently in Bash Shell

You can set an environment variable permanently by placing an export command in your Bash shell's startup script '~/.bashrc' (or '~/.bash_profile', or '~/.profile') of your home directory; or '/etc/profile' for system-wide operations. Take note that files beginning with dot (.) is hidden by default. To display hidden files, use command 'ls -a' or 'ls -al'.

For example, to add a directory to the PATH environment variable, add the following line at the end of '~/.bashrc' (or '~/.bash_profile', or '~/.profile'), where ~ denotes the home directory of the current user, or '/etc/profile' for ALL users.

(For Java) You can set the CLASSPATH environment variables by adding the following line. For example,

Take note that Bash shell uses colon (:) as the path separator; while windows use semicolon (;).

To refresh the bash shell, issue a 'source' command (or re-start the bash shell):

(Notes) For the older csh (C-shell) and ksh (Korn-shell)

• Use 'printenv' (or 'env') to list all the environment variables.
• Use 'setenv varname value' and 'unsetenv varname' to set and unset an environment variable.
• Use 'set varname=value' and 'unset varname' to set and unset a local variable for the current process.

PATH Environment Variable

Most of the Unixes and macOS use the so-called Bash Shell in the 'Terminal'. When you launch an executable program (with file permission of executable) in a Bash shell, the system searches the program in ALL the directories listed in the PATH. If the program cannot be found, you will get the following error:

Take note that the current directory (.) is not searched, unless it is included in the PATH. To run a program in the current directory, you need to include the current path (./), for example,

To list the current PATH, issue command:

How to Add a Directory to the PATH in macOS/Linux

To add a directory to the existing PATH in macOS/Unixes, add the following line at the end of one of the startup scripts, such as '~/.bashrc', '~/.login' '~/.bash_profile', '~/.profile' (where ~ denotes the home directory of the current user) or '/etc/profile' for ALL users.

To refresh the bash shell, issue a 'source' command (or re-start the bash shell):

To verify the new setting, launch CMD:

Notes:

• Unixes/macOS does not search the current directory (.), unless you include it explicitly in the PATH. In other words, to run a program in the current directory, you need to provide the directory (./), for example, You could include the current directory in the PATH, by adding this line in a startup script: (Windows searches the current directory (.) automatically before searching the PATH.)
• Unixes/macOS uses colon (:) as the path separator; while Windows uses semicolon (;).

Java Applications and the Environment Variables PATH, CLASSPATH, JAVA_HOME

Many problems in the installation and running of Java applications are caused by incorrect setting of environment variables (global system variables available to all the processes/users running under the Operating System), in particular, PATH, CLASSPATH and JAVA_HOME.

PATH

When you launch a program from the command line, the Operating System uses the PATH environment variable to search for the program in your local file system. In other words, PATH maintains a list of directories for searching executable programs.

PATH (For Windows)

When you launch an executable program (with file extension of '.exe', '.bat' or '.com') from the CMD shell, Windows searches for the executable program in the current working directory, followed by all the directories listed in the PATH environment variable. If the program cannot be found in these directories, you will get the following error:

For example, if you are trying to use Java Compiler 'javac.exe' to compile a Java source file, but 'javac.exe' cannot be found in the current directory and all the directories in the PATH, you will receive the following error:

PATH maintains a list of directories. The directories are separated by semicolon (;) in Windows.

For Java applications, PATH must include the following directories:

• JDK's 'bin' (binary) directory (e.g., 'c:Program Filesjavajdk1.x.xbin'), which contains JDK programs such as Java Compiler 'javac.exe' and Java Runtime 'java.exe'.
• 'c:windowssystem32' and 'c:windows' which contain console programs and commands.

The JDK's 'bin' directory should be listed before 'c:windowssystem32' and 'c:windows' in the PATH. This is because some older Windows systems provide their own Java runtime (which is often outdated) in these directories (try search for 'java.exe' in your computer, you may find a few entries).

To add a directory (say JDK's 'bin') to the existing PATH, check 'How to add a directory to the PATH'.

PATH (For macOS/Linux)

Most of the Unixes and macOS use the so-called Bash Shell in the 'Terminal'. When you launch an executable program (with file permission of executable) in a Bash shell, the system searches the program in ALL the directories listed in the PATH. If the program cannot be found, you will get the following error:

For example, if you are trying to use Java Compiler 'javac' to compile a Java source file, but 'javac' can not be found in the list of directories in the PATH, you will receive the following error:

To support Java applications, you need to include the JDK's 'bin' (binary) directory in the PATH. See 'How to add a directory to the PATH'.

CLASSPATH

Java Archive (JAR) File

Mac User Library Path

For ease of distribution, Java classes are often archived (zipped) together into a so-called JAR file. To use a third-party Java package, you need to place the distributed JAR file in a location that is available to the Java Compiler and Java Runtime.

How Classes are Found?

Java Compiler ('javac'), Java Runtime ('java') and other Java tools searches for classes used in your program in this order:

1. Java platform (bootstrap) classes: include system classes in core packages (java.*) and extension packages (javax.*) in 'rt.jar' (runtime class), 'i18n.jar' (internationalization class), charsets.jar, jre/classes, and others.
2. Java Extension Directories: You can copy the external JAR files into Java Extension Directory (This is removed and not applicable from JDK 10).
   • For Windows, the Java Extension Directory is located at '<JAVA_HOME>jrelibext' (e.g., 'c:Program FilesJavajdk1.7.0_{xx}jrelibext').
   • For macOS, the JDK extension directories are '/Library/Java/Extensions' and '/System/Library/Java/Extensions'.
   • For Ubuntu, the JDK extension directories are '<JAVA_HOME>/jre/lib/ext' (e.g., '/usr/user/java/jdk1.7.0_{xx}/jre/lib/ext') and '/usr/java/packages/lib/ext'.
   The location of Java's Extension Directories is kept in Java's System Property 'java.ext.dirs'. You can print its contents via System.out.println(System.getProperty('java.ext.dirs')).
3. User classes search path (in short, class path): determined in the following order:
   1. Defaulted to the current working directory (.).
   2. Entries in the CLASSPATH environment variable, which overrides the default.
   3. Entries in the -cp (or -classpath) command-line option, which overrides the CLASSPATH environment variable.
   4. The runtime command-line option -jar, which override all the above.
   The user class paths are kept in Java System property 'java.class.path'.
   It is recommended that you use the -cp (or -classpath) command-line option (customized for each of your applications), instead of setting a permanent CLASSPATH environment for all the Java applications. IDE (such as Eclipse/NetBeans) manages -cp (-classpath) for each of the applications and does not rely on the CLASSPATH environment.

Cannot Find Classes

If the Java Runtime ('java') cannot find the classes used in your program in all the above places, it will issue error 'Could not find or load main class xxxx' (JDK 1.7) or 'java.lang.NoClassDefFoundError' (Prior to JDK 1.7).

Similarly, Java Compiler ('javac') will issue compilation errors such as 'cannot find symbol', 'package does not exist'.

Notes: External native libraries ('.lib', '.dll', '.a', '.so') are to be found in a path in JRE's Property 'java.library.path', which normally but not necessarily includes all the directories in the PATH environment variable. Otherwise, you will get a runtime error 'java.lang.UnsatisfiedLinkError: no xxx in java.library.path'.

CLASSPATH Environment Variable

The CLASSPATH environment variable could include directories (containing many class files) and JAR files (a single-file archive of class files). If CLASSPATH is not set, it is defaulted to the current directory. If you set the CLASSPATH, it is important to include the current working directory (.). Otherwise, the current directory will not be searched.

A common problem in running hello-world program is: CLASSPATH is set but does not include the current working directory. The current directory is therefore not searched, which results in 'Error: Could not find or load main class Hello'. You can simply remove the CLASSPATH, and leave the class path defaulted to the current directory.

For a beginner, no explicit CLASSPATH setting is required. The default CLASSPATH setting of current directory is sufficient. Remove all CLASSPATH setting if there is any. However, if you have to set CLASSPATH, make sure that you include the current directory '.'.

The PATH environment variable (for searching the executable programs) is applicable to all applications; while CLASSPATH is used by Java only.

Read JDK documents 'Setting the CLASSPATH' and 'How Classes are Found' (you can find the hyperlinks from the index page of the JDK documentation, or googling).

CLASSPATH Environment Variable (For Windows)

The CLASSPATH accepts directories and jar-files. Path entries are separated by semicolon (;).

Example: Displaying and changing CLASSPATH for the current CMD session.

You can set the CLASSPATH permanently. See 'How to Set an Environment Variable'.

CLASSPATH (for macOS/Ubuntu)

1. To set the CLASSPATH for the current session, issue this command: Use colon ':' as the path separator (instead of semicolon ';' in Windows).
2. To set the CLASSPATH permanently, place the above export command in the bash shell initialization script (.bashrc or .bash_profile of the home directory or /etc/profile for all users). See 'How to Set an Envrionment Variable'.

User Library Path Mac

JAVA_HOME and JRE_HOME

Many Java applications (such as Tomcat) require the environment variable JAVA_HOME to be set to the JDK installed directory.

How to Set JAVA_HOME in Windows

First, check if JAVA_HOME is already set by start a CMD and issue:

If JAVA_HOME is not set, you will receive 'Environment variable JAVA_HOME not defined'. Otherwise, the current setting will be shown.

To set/change JAVA_HOME in Windows:

1. Launch 'Control Panel'
2. 'System'
3. 'Advanced system settings'
4. Switch to 'Advanced' tab
5. 'Environment variables'
6. Choose 'System Variables' (for all users)
7. To add a new environment variable 'JAVA_HOME':
   1. Choose 'New'
   2. In 'Variable Name', enter 'JAVA_HOME'.
   3. In 'Variable Value', click 'Browse Directory...' and navigate to the JDK installed directory (e.g., 'C:Program FilesJavajdk-15.0.xx').
   4. OK ⇒ OK ⇒ OK.
8. To change the existing 'JAVA_HOME' setting:
   1. Select 'JAVA_HOME' ⇒ 'Edit'
   2. In 'Variable Value', click 'Browse Directory...' and navigate to the JDK installed directory (e.g., 'C:Program FilesJavajdk-15.0.xx').
   3. OK ⇒ OK ⇒ OK.

You need to RE-START CMD for the new setting to take effect!

To verify the new setting, re-start CMD:

How to Set JAVA_HOME in Linux/macOS (Bash Shell)

First, check if JAVA_HOME is already set by start a terminal and issue:

JAVA_HOME is to be set to the JDK installed directory. You need to find your JDK installed directory.

[TODO] find macOS and Ubuntu JDK installed directory.

Add the the following line at the end of '~/.bashrc' (or '~/.login'). Take note that filename beginning with dot (.) is hidden by default.

[TODO] How to un-hide for macOS/Ubuntu.

You need to refresh the bash shell for the new settings to take effect. Issue a 'source' command as follows:

Windows vs. Unixes/macOS

Java is platform independent. Java classes run in Windows as well as Unixes - binary compatible.

• Unixes have many shells, such as the newer bash and the older csh, ksh. Windows have two shells: the newer cmd.exe and the older command.com. Each shell come with its own set of commands, utilities, and its own scripting programming language.
• Unix's variable name is denoted as $varname, e.g., $CLASSPATH. Windows uses %varname%, e,g., %CLASSPATH%.
• Unix uses command 'printenv' (print environment) or 'env' to list all the environment variables. Windows uses command 'set'.
• Unix's PATH is set permanently in the login or shell initialization script (e.g., '~/.login', '~/.profile', '~/.bashrc', '~/.bash_profile', or '/etc/profile'). Windows' PATH is set permanently via Control Panel ⇒ System ⇒ ....
• The current directory is NOT included in the Unix's PATH implicitly. To run a program in the current directory, you need to issue './programName' where '.' denotes the current directory. It is recommended to include the current directory (.) in the PATH explicitly. On the other hand, current directory is included in Windows' PATH implicitly.
• A Windows' path includes a drive letter and directories. Each drive has a root directory. It uses back-slash ' as directory separator (e.g., 'c:jdk1.6bin'). Linux's paths do not have drive letter. There is a single root. Unix uses forward slash '/' as the directory separator (e.g., '/usr/bin/jdk1.6').
• Windows use semicolon ';' as path separator (e.g., in PATH environment variable), while Unix uses colon ':'.
• Windows/DOS uses '0D0AH' (carriage-return plus line-feed) as line-break (or End-of-Line (EOL), or newline). Unixes/macOS uses '0AH' (line-feed) only.

• Tips
• Programs
• On-Line Docs
• Books

QUESTION: How do I download and install the Coyote Library? For that matter, how do I install anythird-party IDL library?

ANSWER: You won't work with IDL for too long before you realize that much of the power of IDL comes from using IDL code foundin third-party libraries on the Internet. The IDL AstronomyLibrary, maintained by Wayne Landsman, and the JohnsHopkins Applied Physics Lab Library, maintained by Ray Sterner, are two of the most famous and widely used. IDL has an extremely robust traditionof excellent IDL programmers sharing their best work with the IDL community. Totake advantage of this software, you have to know how to install the library ofcode and place it on your IDL path (i.e., the !PATH system variable) so you can use it.

The Coyote Library is anotherextremely popular library of IDL code. Indeed, it has become almost too popularand you will find parts or all of it incorporated into other libraries that you findon the Internet. (The NASA Astronomy Library, for example, now uses the Coyote Libraryfor all of its graphic operations.) This is extremely gratifying to the library's author, but causes many gray hairs, too, because the Coyote Library distributed with these otherlibraries is often out of date. This makes it difficult for many users to install the Coyote Library properly and make use of all of its functionality.

The installtion and set-up directions here can be used to installthe Coyote Library, the Catalyst Library, or indeed any third-party IDL library you care to use in your IDL installation.

Managing Your IDL Path

A great many IDL programmers are still unsure how to set up and use their IDL path. The IDL path is a list of directories that are searchedwhen IDL needs to find the source code for a user-written IDL 'command'or program.The typical scenario is that a young graduate student comes into a lab and theirIDL installation is 'configured' for him or her by a senior graduate student,whose own IDL installation was 'configured' for them another senior graduate student, etc.In this scenario it will turn out that everyone in the lab is using an IDL start-upscript that was written in 1986 by the founder of the lab, everyone writes IDL code as if it were a direct translation of a FORTRAN program,and not a single person in the lab knows how or why their IDLpath has gotten so convoluted and confusing. The fact that IDLeven 'works' seems like magic to them!

When wading into Coyote Library installationproblems, it is not the least bit unusual (especially on UNIX systems), to find 4-5 old and out-of-date copies of the Coyote Library in a user's IDL path. The useralmost never knows how they got there.

Let me be absolutely clear about this. You want ONE version of theCoyote Library in your IDL path!

(A new program, named cgFindCoyoteFiles has been added to the Library to help you findand eliminate old and out-dated versions of Coyote Library files. Runningthe program will print of list of directories on your IDL path that theprogram strongly suspects contain Coyote Library files. If you finddirectories that do contain old and out-dated Coyote programs, you shoulddelete those directories before proceeding.)

The general procedure is to first download the entire Coyote Library (or Catalyst Library) as a zip file. Then, unzip the file and extract the programs to a directory that is already on your IDLpath, or to a directory you intend to put on your IDL path (see detailed instructions below).You can also download the Coyote and Catalyst Libraries from aSubversion code repository. You must have aSubversion client installed to use the repository, however. (Many UNIX systems have this installed by default and I highly recommend Windows users downloadthe TortoiseSVN application to use for this purpose.) The Subversionrepository is highly recommended as this is the main repository for all the workI do on these Libraries. You can use the repository to update to the very lastest versionof the Libraries, or to a particular tagged release. The zip files always contain the verylatest version of the Library.

Note that I try extremely hard to keep the Coyote Library free of outside influence. That is to say,even though I personally use many routines from both the IDL AstronomyLibrary and the JohnsHopkins Applied Physics Lab Library, I do not use these routines in Coyote Library programs.Thus, there are no library dependencies in the Coyote Library, except from the normal IDL user library and from the Coyote Library itself. (I can think of a single exception to thisrule, cgTerminatorMap, but it is clearly identified as such.) I try hard to keep the Coyote Library away from cutting edge IDL improvments, but life does goes on. If you are using an older (e.g., IDL 6.3) versionof IDL you may find some routines in the Library no longer working for you. If you do,contact me about the problem. It'spossible I can retreive an older version of the program that works for you.

Installation Procedures

1. Download the Coyote Libraryzip file. You can put the zip file wherever you like on your hard drive. (Notethat, if you prefer, you can download the Coyote Library from an open-sourceGoogle Code Subversion repositoryinto a directory on your machine using either a Subversion client orSubversion commands directly.)
2. Extract the zipped files to a local directory. Note that the files will installthemselves into a directory named 'coyote'. It is best not to extract these files toyour Desktop. This will cause problems later on. For example, on my C: drive on my Windows machine, I havea top-level directory named idl. This is the location I would use as the 'extraction' directory and whereI would place the 'coyote' directory. I am going to use the following directory in my examplesbelow.

   You should substitute into the commands the actual location where you installed the files.

   Installation Alternatives

   It would be perfectly fine if you wanted to install the Coyote files in a directory otherthat the coyote directory described above.You could, for example, install the file into a coyote directory located in the lib directory in the main IDL distribution(probably something like C:Program FilesITTIDL8.3lib), if you hadpermission to do so.Or, you can name the directory something entirely different. It is not important what you name it, but how itis found on your IDL path.
3. Given that you have extracted the zip file into the directory above, how do you get the fileson your IDL path? There are many possibilities. Let me tell you one I would not recommend.

   If you add this directory as a project to your IDL Workbench, I strongly recommend that you do notlet IDL manage the path to the files for you. I do recommend you add the files as a project in your Workbench, since this will give you great access to the source code documentation, just do not ever let IDL manage the paths for you. If you add them to your Workbench as a project be sure go to the Project -> Properties -> IDL Project Properties tab and deselect the button that says “Update IDL path when project isopened or closed.”

   To add the files to your IDL path in your IDL Workbench, go to the Window -> Preferences -> IDL -> Paths tab. Click the Insert... buttonand search for the coyote directory. Next, selectthe coyote directory and use the Move Up button to move the coyote directory in front of (toward thetop of the window)of other directories on your path. You should now be good to go. (Note that if you are installing both the Coyote and Catalyst Libraries, the Coyote Library should be positioned before the Catalyst Library in your path list, as programs in the Coyote Library must be found before they are used by programs in the Catalyst Library.) If you still find occasional name conflicts, contact me and I'll see what I can do about it. Some name conflicts are probably inevitable. Play around withthe order of your files in this path list until you are happy.

   Adding the Coyote Library to your IDL Path.

4. If you are not using the IDL Workbench to run IDL, you might be able to do something similar to theIDL Workbench instructions if you are using an IDLDE. There the IDL path preferences are probably in File -> Preferences -> Path. The Insert... button is still there, but you need to use the arrow buttons to theright of the path list to move and order the directories on your IDL path.
5. If you are using the IDL command line version, or all else fails, you can include the following IDL command in your IDL start-up file, oryou can simply type the command at the IDL command line before you run any Coyote program:

   Note the plus sign (+) at the front of the coyote directory name. This tells IDL to search all of thesub-directories of these directories and add them to the path, too. Note also thatdirectories are separated by a semi-colon on Windows machines.You can have a command like this for as many third-party libraries asyou want to install on your machine. Just pay attention to the order inwhich you define them. The command above adds the library files to thefront of the IDL path. So, if you were using this command toadd multiple libraries, the commands would be listed in the reverse order in which they are going to be found. For example, to add both theCatalyst and Coyote Libraries, you would add them like this, since the coyote directory must be found first on the IDL path, before the catalyst directory.:

   Another way to write this command is like this, in which thelibraries are added in the order in which they will be searched:

   The Coyote Library command, cgAddToPath, can also beused to add the current directory to the front of the IDL path.

1. Download the Coyote Libraryzip file. You can put the zip file wherever you like on your hard drive.
2. Extract the zipped files to a local directory. It is best not to extract the files toyour Desktop. This will give you problems later on.On my local hard drive on my UNIX machine, I havea top-level directory named ~/fanning/idl. This is the location I would use as the 'extraction' directory and whereI would place the 'coyote' directory. I am going to use the following directory in my examplesbelow.

   You should substitute into the commands below the actual location where you installed the files.

   Installation Alternatives

   It would be perfectly fine if you wanted to install the Coyote files in a directory otherthat the coyote directory described above.You could, for example, install the files into a coyote directory located in the lib directory in the main IDL distribution(probably something like /usr/local/ITT/idl70/lib), if you hadpermission to do so.Or, you can name the directory something entirely different. It is not important what you name it, but how itis found on your IDL path.
3. Given that you have extracted the zip file into the directory above, how do you get the fileson your IDL path? There are many possibilities. Let me tell you one I would not recommend.

   If you add this directory as a project to your IDL Workbench, I strongly recommend that you do notlet IDL manage the path to the files for you. I do recommend you add the files as a project in your workbench, since this will give you great access to the source code documentation, just do not ever let IDL manage the paths for you. If you add them to your Workbench as a project be sure go to the Project -> Properties -> IDL Project Properties tab and turn off the button that says “Update IDL path when project isopened or closed.”

   If you make the files a project in your IDL Workbench then add the directory to the IDL path bygoing to the Window -> Preferences -> IDL -> Paths tab. Click the Insert... buttonand search for the coyote directory. Next, selectthe coyote directory and use the Move Up button to move the coyote directory in front of (toward thetop of the window)of other directories on your path. (Note that if you are installing both the Coyote and Catalyst Libraries, the Coyote Library should be positioned before the Catalyst Library in your path list, as programs in the Coyote Library must be found before they are used by programs in the Catalyst Library.) You should now be good to go. If you still find occasional name conflicts, contact me and I'll see what I can do about it. Some name conflicts are probably inevitable. Play around withthe order of your files in this path list until you are happy.

4. If you are not using the IDL Workbench to run IDL, it is more likely that you are defining yourIDL path be defining environment variables in a .cshrc, .bashrc, or .profile file. Forexample, in a .bashrc file, you could add the coyote directory to your current IDL path ($IDL_PATH) by adding a command like this:

   Note the plus sign (+) in front of the coyote directory name. This is an indication thatIDL should expand this path to include all of the sub-directories under this directory and add theseto the IDL path, too.

   I typically define my IDL path in an IDL start-up file. The start-up file is also defined by an environmentvariable ($IDL_STARTUP). For example, in my .profile file I have this line:

   Then, in my IDL start-up file, which is simply a text file that gets executed upon starting up IDL,as if I were typing the commands at the IDL command line, I have the following lines of code which definemy IDL path in the order in which the directories appear here:

   Note the plus sign (+) at the front of the coyote and catalyst directory names. This tells IDL to search all of thesub-directories of these directories and add them to the path, too. Note also thatdirectories are separated by colons in a UNIX environment.

5. If all else fails, you can simply type the following IDL command at the IDL command line before you run any Coyote program:

   Note the plus sign (+) at the front of the coyote directory name. This tells IDL to search all of thesub-directories of these directories and add them to the path, too.The Coyote Library command, AddToPath, can also beused to add the current directory to the front of the IDL path.

Not all naming conflict problems are easily resolved. If you think you are still havingproblems after following this advice, here is how to determine what the problem is. Firstof all, determine which file actually got compiled. For example, if you are running intoa problem with a program like PSCONFIG, it is likely that you may have another program withthis name on your path, and you are compiling this first, rather than the one you want inthe coyote directory. To see which one you compiled, type this:

Now search the output list for “PSCONFIG” and you will find where IDL located the file.

Another way to do this, assuming you know the name of the file you are looking for, is touse the File_Which command in IDL:

User Library Path Example

Typically, file naming conflicts are resolved by either moving directories around on the IDL path,or by deleting old files from other directories that are no longer needed. (The latter is highly recommended for the Coyotedirectory. And you can chase down and eliminate old and out-datedCoyote libraries with the cgFindCoyoteFiles program.)

Another way to check for multiple coyote directories on yourIDL path is to type the Coyote Library command PrintPath. This will list all the directories on your IDL path in the order in whichthey are searched, one directory on each output line. You can searchthe output for 'coyote,' for example, to find and eliminate multiplecoyote directories on your path. (You can specify the name of a file as an argument to PrintPath to write the output to a file for easier searching if you have many directories on your IDL path.)

Qemu User Library Path

Version of IDL used to prepare this article: IDL 7.1.