Unix at D0

Your Environment

Startup and Configuration Files | Shell Variables | Commands

For more information about your Unix environment, refer to the Working Environment chapter in Unix at Fermilab.

Startup/configuration files

Your environment can be customized to meet your needs and/or esthetical standards. This is usually done with the help of various startup and configuration files. These are shell scripts which typically reside in your home directory, and have their names stating with a dot (period). Files starting with a dot are called "dot files" and are not reported by an ls command, unless option -a is used, or you specifically asks for them, like ls .*

A very efficient way for a beginner to customize his/her environment is to look at other people's startup files.

The issue of login scripts is very complicated. Different shells do things very differently. Different sites require different things depending on what the system-wide ones do. However, here are a few simple suggestions:

1. Keep the amount of stuff you do in the configuration/login scripts to a minimum. You want to be able to login fairly quickly. You don't want them to fail if a disk is down or anything like that. So define aliases (csh/tcsh) or functions (sh/bash/ksh) for common functions/setups and type those when needed.
2. .profile (sh/bash/ksh) and .login (csh/tcsh) are sourced only once at login. So you can put anything you want there, subject to the advice above.
3. .*rc (.cshrc for csh/tcsh, .shrc or .bashrc or .kshrc for sh/bash/ksh but see the man pages. bash and ksh will source .shrc under certain conditions) are invoked at almost every subshell invocation. Since exes, including scripts that aren't sourced, run in subshells, Unix creates a lot of them. When you do a gmake, essentially every line of every rule is a seperate subshell. So .*rc can be sourced thousands even millions of times per session. Do not put much there!
4. Environmental variables are passed to subshells. So there is no need to define those in .*rc
5. . But see Shell Variables below. Shell variables though much like environmental variables are not passed to sub shells.
6. Aliases and functions are not passed to subshells. That is why .*rc exists. So define those in .*rc, but only those that you really need.

NOTE OF CAUTION: do not redefine system commands using aliases or functions in your login scripts or elsewhere. Many scripts and programs rely upon a certain behaviors of the standard commands. Changing those behaviors can break those scripts and programs. For example, changing the cd command to echo the new location breaks the SoftRelTools build system used by D0, CDF and others. Instead, make up a new name, say, cde for cd echo.

csh and tcsh customization

csh (and tcsh) use three customization files. At the login time two of them are executed: .login and then .cshrc. Whenever a new shell is started, the .cshrc file is executed in the new shell. At the logout time the shell invokes .logout file.

• .login file
  It is executed once per session, at the login time. To be in sync with local fermi environment it should include:

  source /usr/local/etc/fermi.login
  

• .cshrc file
  This file is executed after the .login file, and at the startup of every new csh. It should contain definition of environmental and shell variables, aliases etc. This is a good place to setup products like www, emacs, etc. In particular it is strongly recommended that the following two lines are included:

  source /usr/local/etc/fermi.cshrc
  

• .logout file
  It is invoked when you logout from a session. It may store some information about the session for a future reference.

Bourne, Bash and Korn shell initialization

If you are thinking about using these shells, you presumably know what you are doing. For completeness, though, we mention that these shells invoke .profile file at the login time.

Korn and Bash shells execute in addition a file .kshrc and .bashrc every time a new shell is created. In fact you may customize your Korn and Bash shell environments, by invoking different startup files, depending on your need. This can be done by defining an environmental variable ENV referring to the desired file.

Start-up files in X

X Windows is very flexible and very powerful. The first relates to a large number of ways of achieving a desired goal, the second to a large number of possible configuration parameters, resources, etc. The longer you live in X environment, less confusing it becomes.

Start-up files can be categorized into:

• initialization files
• resource files
• startup files for the window manager

Initialization files

An X Window System can be started in different ways and, sure enough, different startup files are involved. It gets complicated real fast, therefore only some hints are given here:

• the X system has been started via xinit
  If a file .xinitrc exists in the your home directory, xinit will execute it instead of just creating a terminal window. An .xinitrc file may contain:

      xclock -geom 150x150+1105+7 -hd green -hl yellow -bg pink -fg red &
      xterm -ls  -fn 10x20 -sb -sl 500 &
      mwm
  

  Notice that the processes are started in the background. The last line invokes a window manager and xinit will transfer control to it.

  An important variation of this method is a remote session, for example over the phone line. In this case there are two possibilities: you can run xinit on the terminal server (preferred) or on the remote node. In the latter case you will invoke xinitremote, which will execute a file .xinitremoterc. Your .xinitremoterc file may look like:

      xclock -geom 150x150+1105+7 -hd green -hl yellow -bg pink -fg red &
      xterm -ls  -fn 10x20 -sb -sl 500
  

  Notice that in this example you do not start a window manager, as presumably you are running a local window manager on your X-terminal.

• the X system has been started via xdm, when you are logging in.
  This is a typical case when you log in on the workstation directly. The relevant startup file is .xsession (as usual, in your home directory).

Resource files

These are files used to customize various products, Netscape and Mosaic, editors, mail handlers, etc.. etc... They define various parameters controlling appearance and functionality of the programs, they can even define application-specific keyboard mapping, if so desired.

An important resource file is .Xdefaults. Its format is:

application_name*resource_name      value

Here are some example lines from a .Xdefaults file:

emacs*font:                                10x20
Mosaic*anchorColor:                        red
4Dwm*keyboardFocusPolicy:                  click

In addition to the .Xdefaults file applications may be taking their parameters from the application-specific configuration files, for example:

Configuration file        Application

.emacs                      emacs
.explorerrc                 explorer
.mh_profile                 MH
.mailcap                    mosaic
.piafrc                     piaf

startup file for window manager

This file (.mwmrc) is used to define parameters, menus, etc. for your window manager. You can define your own menus, or substitute your own programs to be invoked from the standard menus.

Shell Variables

Shell variables are known only to the current shell. Shell variable definitions are not inherited by child processes. Any standard shell variables must be defined each time a new shell is created, typically in one's .cshrc file.

Standard D0 shell variables are defined by sourcing /usr/local/etc/d0local.cshrc. Shell variables are used to store standard options for compilation and linking. They do not normally need to be referred to by users.

Commands

The UNIX shells provide two mechanisms for defining non-shell commands -- aliases (csh/tcsh) or functions (sh/bash/ksh) and executable files. An executable file may be a script or a compiled program.

Aliases and Functions

An alias is a short (one-line) command that is invoked by a specified character string and is executed by the current shell. Alias definitions are not inherited by child processes, but must be redefined in each shell, normally in one's .cshrc file.

The alias command is supported by ksh and bash, but not sh. For the entire Bourne shell family you can use shell functions instead of aliases. The format of the alias command is:

% alias  = '<alias contents>'

The example below causes ls -l to be executed when the command ll is entered:

% alias ll='ls -l' 

Functions (bash shell family) are declared using this syntax:

[ function ] name () { command-list; }

This defines a function named name. The word function is optional. If function is supplied the parentheses are optional. The command list is executed whenever name is specified as the name of a command.

Shell Scripts

A shell script is a file containing a number of commands that can be executed as one command. You can define variables, process arguments, define flow control, loops and conditionals, and perform I/O. It provides services like pipes, input/output redirection, variable substitution and allows you to report errors, status and results of the commands. Details depend on which shell you are using for the script.

Normally when you execute a shell script, it starts in a subshell of your current shell. At the end of the script, control returns to the parent shell, and any definitions made by the subprocess are not passed back to the parent process. If you want to execute a script in your current shell, you can use the source command:

% source scriptname

Shell scripting resources:

• Shells chapter of Unix at Fermilab
• Shell Programming from Stanford University's School of Earth Sciences

Executable Files

Executable files are executed as separate processes from the parent shell. They inherit a copy of the parent shell's environment variables (not shell variables or aliases). Since they are a separate process, they can not modify any aspect of the parent shell's variables or aliases.

d0web-support@fnal.gov
Security, Privacy, Legal
Last modified: May 07, 2004 11:15:56 AM CDT