UNIX/Linux/X Window Help
Description
This page is intended to provide basic Unix/Linux and X Window help on general issues and problems related to using various SCV supported software packages.
Topics
New accounts should be set up already with no need to run dotfiles yourself unless you delete or corrupt one of your dotfiles (.cshrc, .login, ....). If you do need to reset your dotfiles, you should run the program /usr/local/bin/dotfiles. This program will allow you to back up your existing dotfiles and install new dotfiles which should provide you with a good, basic working environment on each SCV machine you run it on.
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.
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 exampleapp, you might need to directly specify the exampleapp path (/usr/sbin/exampleapp perhaps) 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/scv/aarondf/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/scv/aarondf/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.
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
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.
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:
pen.bu.edu aarondf
Given this, I could ssh to twister without needing to enter my password from pen.
Using a .rhosts file
Once created, a .rhosts file allows you to do two things
- ssh or rlogin from a trusted host without typing your password.
- 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 cootie.
twister% scp ~aarondf/testfile cootie:~aarondf/.
Copy a sub-directory (and all of its contents) of my current directory on twister to my directory under /scratch on cootie.
twister% rcp -r directory cootie:/scratch/aarondf/.
See the man page on scp or rcp for more information and help.
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
and this will return a list of the form:
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.
In order to run an application directly from the console of a machine you are logged into (pen.bu.edu in this example), your DISPLAY environment variable needs to be set appropriately. This in most cases will automatically be the case already on our machines but if you need to set it yourself, you do so by running:
pen% setenv DISPLAY pen:0.0
Note that because you are using the console, you can also generally replace "pen:0.0" in the above line with ":0.0" or "unix:0.0". Also, your DISPLAY environment variable must be set correctly in every window from which you wish to launch an application which brings up windows.
Having set your display, you should simply be able to run your application and have it display on the console you are sitting at.
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.
Document Name: scvxhelp
Author/Maintainer: Aaron D. Fuegi (aarondf@bu.edu)
Keywords: display, path, environment, dotfiles, source, rhost, rcp
Related Man Pages: source, rcp
Created August 17, 1995; Last Revised July 16, 2009; Last Modified
September 15, 2009
URL of this document: http://scv.bu.edu/documentation/software-help/system-usage/xstuff.html
Go up to SCV Software Packages
|