UNIX/X Windows Help

Description

Topics

• Setting up basic dotfiles
• Running an application from a machine's console
• Allowing applications to display information to your machine
• Running an X application from a remote machine
• Sourcing files
• Adding items to your path
• Adding a directory to your LD_LIBRARY_PATH
• Setting environment variables
• Creating and using a .rhosts file.
• Listing and killing stray processes.

Setting up basic dotfiles

Running an application from a machine's console

barbie% setenv DISPLAY barbie:0.0

Having set your display, you should simply be able to run your application and have it display on the console you are sitting at.

Allowing applications to display information to your machine

Programs running on remote machines can not display information to your screen unless you give them the authority to do so. You can do this using either the xhost or the xauth program. xauth is more security conscious but xhost is easier to use.

In the simplest case, if your local machine (or if you are on an Xterminal, the server you are logged in through) is barbie and you wish to allow an application running on twister to display information to your screen, do the following:

barbie% xhost + twister

Running an X application from a remote machine

The following instructions apply if the machine you are sitting at is a Unix machine. If you are on a Windows PC or Macintosh, go here for instructions on installing an X emulator on your machine.

In order to run an X application from a remote machine and have it display to your local machine/terminal, you need to set the DISPLAY environment variable correctly on the remote machine and, on your local machine, allow the remote machine to display graphics on your local machine.

Example1: You are logged into a physical machine (example local machine: marby) and wish to run an X application (example application: idl) on another machine (example remote machine: twister).

marby% xhost + twister

twister% setenv DISPLAY marby:0.0
twister% idl

Example2: You are using an Xterminal (example Xterminal: pub4-cxt1.bu.edu) and logged in through a server machine (example local machine/server: cgl) and wish to run an X application (example application: idl) on another machine (example remote machine: twister).

On the local machine/server, allow the remote machine to display graphics through the local machine:

cgl% xhost + twister

twister% setenv DISPLAY pub4-cxt1.bu.edu:0.0
twister% idl

Sourcing files

Sourcing a file basically means to run it as a script. It is done most often with dotfiles and files which set up basic environment variables and other things needed to run a given application.

In order to source a file, such as your .cshrc, you simply need to run the command:

twister% source .cshrc

If you find yourself sourcing a given file almost every time you log in, you may want to add the appropriate source command to one of your dotfiles, such as your .cshrc or .tcshrc. If you do this, the file will automatically be sourced every time you log in. However, if you wish to immediately take advantage of this change without logging out, you will have to either directly source the original file or source the .cshrc or .tcshrc file you just changed.

Adding items to your path

Your path defines in which directories, when you type a command, the machine will look to find the command you typed. If the system returns a message saying "command: Command not found", that indicates that either the command doesn't exist at all on the system or it is simply not in your path. For example, to run explorer, you would need to directly specify the explorer path (/usr/sbin/explorer on SGIs) or you need to have the directory /usr/sbin in your path. If you didn't have that directory in your path, you could add it to the end of your existing path (the $path represents this) by issuing the command:

twister% set path=($path /usr/sbin)

Also, note that the order in which items appear in your path is important as, if two items have the same name, the one which is in the directory appearing earliest in your path will be executed. For example, maybe you have written a program and compiled it and named it test. Well, it turns out that a program named test already exists on most systems in /usr/bin/test. As such, if the directory /usr/bin appears before your current directory (represented in your path by a . symbol) in your path and you just type test, you will run the version in /usr/bin/test and not the program you wrote of the same name. To avoid this, you can either put the . at the start of your path (not recommended) or you can specify the full pathname for your version of test by running /usr1/guest/username/test or you can simply not reuse any command names already on the system (recommended). You can find out the full path to a given command you are running by using the command which. In the example given above, which test would likely return either /usr/bin/test or /usr1/guest/username/test, depending on how your path was set up. You can add items to the front of your path by modifying the set path= command above so that the $path appears after the directory you are adding or you can totally replace your path by leaving out the $path entirely.

As with sourcing files above, you can add path changing commands to your dotfiles, such as your .cshrc or .tcshrc, so that you do not have to change your path manually every time you log in. In fact, this is generally a very good idea to do. A good practice is to put the most important directories towards the front of your path (examples: /bin, /usr/bin, /usr/local/bin) and your current directory ( . ) and application-specific directories towards the end of your path.

Adding a directory to your LD_LIBRARY_PATH

The LD_LIBRARY_PATH environment variable is used by the system to find shared libraries. It is automatically set by the global startup files. Please don't override the system setting. Use the following code in your .cshrc file to add your_directory to LD_LIBRARY_PATH while preserving the system setting:

if ($?LD_LIBRARY_PATH) then
    setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:your_directory
else
    setenv LD_LIBRARY_PATH your_directory 
endif

Setting environment variables

Unix uses environment variables to keep track of defaults for all sorts of purposes. For example, the variable PRINTER lets you set up a default printer to use with lpr. All environment variables have names in ALL CAPS and you can get a list of all the environment variables you currently have set by issuing the command printenv. To set an environment variable, issue a command like setenv ENV_VARIABLE text_string_variable_is_being_set_to. For example, to set your default editor to be emacs on twister you would do:

twister% setenv EDITOR /usr/local/bin/emacs

As with sourcing files above, if you find yourself setting a given environment variable almost every time you log in, you may want to add the appropriate setenv command to one of your dotfiles, such as your .cshrc or .tcshrc. If you do this, the file will automatically be sourced every time you log in. However, if you wish to immediately take advantage of this change without logging out, you will have to source the .cshrc or .tcshrc file you just changed.

Creating and using a .rhosts file.

An .rhosts file on a given machine is used to allow trusted access to given host/user combinations without the need for a password. This has security advantages and disadvantages. The disadvantages are obvious: if a user gets access to your account on one machine, he may automatically have access to accounts on various other machines. On the other hand, using .rhosts files reduces the number of times you need to type your password and this is a security advantage.

For security reasons, we do not allow the use of .rhosts files into our systems from non-SCV systems.

Creating a .rhosts file

A .rhosts file is a simple text file which you can create in any editor with a series of lines of the form "remote_hostname username" specifying that a given username on a given remote system is trusted to automatically access the machine. This file must be named .rhosts and must reside in your home directory. For example, assume the following was my (username: aarondf) .rhosts file on twister:

cgl.bu.edu aarondf

Using a .rhosts file

Once created, a .rhosts file allows you to do two things
1. sssh or rlogin from a trusted host without typing your password.
2. Use the command scp or rcp (remote copy) to copy files/directories from one system to another. For example, given the .rhosts file example above I could do the following:
   Copy a file from my home directory on twister to my home directory on skate.

   twister% scp ~aarondf/testfile skate:~aarondf/.

   Copy a sub-directory (and all of its contents) of my current directory on twister to my directory under /scratch on skate.

   twister% rcp -r directory skate:/scratch/aarondf/.

Listing and killing stray processes.

Users often accidentally can leave background processes running and consuming resources. These stray processes should be eliminated. To get a list of all the processes you have running on a given machine, use the ps command:

twister% ps -ef | grep your_login_name | more

aarondf  69374  84190   0 15:21:07 pts/40  0:00 grep aarondf
aarondf  71930  84190   4 15:21:07 pts/40  0:00 ps -ef
aarondf  84190  52586   0 13:58:51 pts/40  0:00 -tcsh    
aarondf  95408  36098   0 16:03:53 pts/49  0:00 -tcsh

You can kill a given process by doing the command kill -9 PID:

twister% kill -9 84190

The "-9" is not always necessary but makes sure that you kill the process. You can, of course, only kill your own processes. If there are a large number of runaway processes of other people on the system, you can send mail to help@scv.bu.edu and ask us to kill them.

Additional Help/Documentation

If you have problems with any of this, you should ask for general help from the consultants at the Consulting Services Desk in the basement of 111 Cummington Street. You can also request help (particularly SCV-specific help) by sending email to help@scv.bu.edu.