Hamilton LaboratoriesHamilton C shell 2012User guideLanguage reference

Customizing the shell

Oregon Coast

Customizing the shell
Previous | Next

Topics

Install directory
Distribution layout
Start menu and shortcuts
Login.csh
Startup.csh
Environment variables
Prompt strings and title bar
Colors
Initial current directories
Change directory behavior
Berkeley-style history and escapes
Berkeley compatibility mode
Error handling
Calling the C shell from other applications
See also

Install directory

You can choose to install Hamilton C shell anywhere you like. Here are the defaults.

Windows C shell Default installation directory
64-bit 64-bit C:\Program Files\Hamilton C shell 2012 x64
32-bit 32-bit C:\Program Files\Hamilton C shell 2012
64-bit 32-bit C:\Program Files (x86)\Hamilton C shell 2012

Distribution layout

These are the directories and files that make up the distribution for Hamilton C shell.

Hamilton C shell distribution directory contents
Directories
Bin The binary executable files for the C shell and all the external utilities.
Samples A directory containing various sample scripts and simple C programs.
Setup Scripts used during install or uninstall and a log of the installation.
UserGuide The HTML files comprising this user guide.
Files
License.rtf The Hamilton C shell license agreement.
Login.csh The default login.csh file.
ReleaseNotes.txt Release notes detailing changes from one build to the next.
Startup.csh The default startup.csh file.

Start menu and shortcuts

During installation, you’ll be asked whether it’s for everyone or just for yourself. If you choose everyone, the Hamilton C shell group will be created in the everyone's Start menu. If you choose just yourself, it will only appear in your own Start menu. Another shortcut to the C shell is created on either your desktop or the desktop shared by all users.

The shortcuts open the C shell in a 25 line x 80 character window of white characters on a blue background as a "login" shell, causing it to look for a login.csh file. To change those selections, right-click on shortcut and select Properties.

Login.csh

login.csh is read only by copies of csh.exe started with the -L option to make them login or root shells. Typically, this is a new window. startup.csh is read by each new copy of the shell, even if it’s invoked as a child of the C shell.

The main objective of the login.csh file is to let you set up those characteristics that are inheritable from parent to child process but which might not be set up if you’re starting from the desktop. In addition, it lets you do a little special customization of these highest-level shells.

The important inheritable characteristics are the environmental variables together with the current directories and current disk settings.

Startup.csh

The startup.csh file is read by all copies of the C shell, not just login or root level copies. If you don’t want the startup file read, you have to specifically tell it with the -F (Faster startup) option. startup.csh is read after login.csh whenever both are being read. This means you can depend on the environmental variables being set up already when the startup file runs.

startup.csh is a good place to define any aliases or function key definitions you use, since you’d probably always want them available but can’t pass them in the environment to any child copies of csh.exe. The startup.csh file that comes with the shell defines a number of popular aliases including some for getting at some of cmd.exe’s internal functions; most people add a few of their own.

The other thing you may want to add to your startup.csh file are settings for some of the set variables that customize how the shell runs. These aren’t passed in the environment. Look through the lists in the Language Reference section. Some you may want to set differently than the defaults are bsdhistory, cdhome, chgdisk, escapesym, histchars, ignoreerrors, ignorestatus, noclobber, nonomatch, nullwords and tailstatus. A lot of what you choose will depend on whether you’re coming from a Windows or a Unix background.

Environment variables

It's convenient to set up environmental variables used only by the C shell in login.csh rather than via the Control Panel. It means just one copy of the definitions in one place, so it’s easier to make changes and know they won’t affect other installed applications.

In addition to PATH, the environmental variables used by Hamilton C shell include HOME, PROMPT1 and PROMPT2, CSHTITLE, TABS, CDPATH, DRIVEMASK, MIXEDCASEDRIVES, SWITCHCHARS and a number of screen color configuration variables.

PROMPT1 or PROMPT2 or their aliases prompt1 and prompt2 control the prompt strings you’ll see for a new command or a continuation line. CSHTITLE or its alias, cshtitle, give you similar control over the text in the title bar.

TABS is used by more, head, tail and other utilities to expand out any tab characters it sees into space characters on the screen. For example, setting TABS = 3 means tabstops every 3 character cells.

CDPATH is used by cd and pushd to specify other directories in addition to the current directory in which to search for a subdirectory you’re trying to change to. Its format is the same as that as PATH: a list of directories separated by semicolons, but there’s no need to list the current directory.

DRIVEMASK lets you confine the default list of drives you want searched when you wildcard a driveletter, e.g., *:\hamilton or reported on by the du, pwd and vol utilities. The value should be a list of upper- or lower-case alphabetic characters or ranges of characters representing the drives you’re interested in. For example, setting DRIVEMASK = cf-h means you want drives C:, F:, G: and H: reported, assuming they exist.

MIXEDCASEDRIVES is used by ls, by the shell’s fullname and wildcarding functions (including filename completion), by the current directory functions (cd, pushd, popd and dirs) and by pwd to tell which drives you want reported in the actual upper or lower case characters returned by the Windows kernel. You set MIXEDCASEDRIVES just like DRIVEMASK, giving it a list of drives. It’s also possible to list UNC names that should be considered mixed case. For example, typing

setenv MIXEDCASEDRIVES = a-z,\\

sets all drive a: through z: and all UNC names on all networked machines as mixed case, which happens to be the default if is MIXEDCASEDRIVES undefined. Or for example, typing

setenv MIXEDCASEDRIVES = \\alpha,\\beta\d$

sets all the drives on the alpha machine and only the d: drive on beta as mixed case. You can list as many entries in MIXEDCASEDRIVES, separated by commas, semicolons or spaces, as you wish.

SWITCHCHARS is used by the shell and all the utilities supplied with it to indicate what characters you intend as introducing one of the option switches. By default, the C shell tries to satisfy users coming from both Windows and UNIX backgrounds and will accept either - (Windows-style) or / (UNIX-style) as introducing an option. Folks coming from a straight UNIX background may find that inconvenient, particularly if they’re used to typing filenames using the forward slash; cd /foo will certainly not do what they want, for example. The solution is to setenv SWITCHCHARS = -, causing only those words that start with - to be recognized as options.

Prompt strings and title bar

Prompt strings and title bars are fairly personal matters. This really is beauty in the eye of the beholder only!

For the prompt, there are two situations:

  1. The main prompt, when the shell expects a new command. Set this with PROMPT1.

  2. Continuation lines, where the shell is collecting more text before running something. An example would be whatever commands you type inside a foreach loop. Set this with PROMPT2.

When the shell needs to prompt you, it looks at the appropriate PROMPTx string and evaluates it as if it were looking at a double quoted string. Any backquoted strings or variable substitutions it finds there are evaluated and whatever results is printed. Wildcards are not replaced nor is the spacing affected. It’s quite literally double-quoted: the shell actually pastes double quote characters around the string before passing it to the parser.

If you always wanted the same literal text string displayed, that would be easy but probably not too interesting:

579 D% set PROMPT1 = "Hello from CSH! " Hello from CSH! _

The difficult part of setting your prompt is remembering that if you want a substitution re-evaluated each time a new prompt is printed, you have to quote the string when you define it to defer the evaluation. Here’s the wrong, then the right way to create an old MSDOS-style prompt with your current directory upper-cased inside rectangular brackets.

Hello from CSH! set PROMPT1 = "[$upper(cwd)] " # Wrong way [D:\NICKI] cdd c:\ # Notice that the prompt won't change [D:\NICKI] set PROMPT1 '[$upper(cwd)] ' # Right way [C:\] _

Notice how we’re using the builtin upper procedure as if it were a variable substitution with the $ in front. When the shell sees it’s really a procedure reference, what’s inside the parentheses is evaluated as an expression list. That’s why the cwd variable didn’t need its own $.

There’s really no limit to what you can put inside a prompt string. You can have command substitution and special characters. It can even stretch over multiple lines if you put in carriage return/newline character combinations:

[C:\] set PROMPT1 = '`date`^r^n$cwd ' Fri Jul 22 2011 8:57:22.03 c:\ _

The title bar environmental variable, CSHTITLE, and its shell variable alias, cshtitle, work pretty much the same way as the prompt variables. The title bar is recomputed every time the shell prompts for a new command. If CSHTITLE is null, “Hamilton C shell” is displayed. If CSHTITLE is explicitly unset, the title bar text inherited at startup is displayed. Otherwise the CSHTITLE string is evaluated as if it were a double-quoted string.

The tradeoff to remember in creating a prompt or title string is that whatever you put there is going to be run every time you need a new prompt. If you make it too complex, it’ll still run, but it could be annoyingly slow. Remember that it takes longer to run external programs than to use shell variables or procedures. If you want something really unusual, try writing a procedure that calculates and returns the string you want.

Colors

All of the screen colors used by the C shell and any of the utilities are completely under your control. Here are the variables that control the color settings and default values:

Name Use Default
ADDITIONS

Lines added found by diff.

Bright White on Green
COLORS

Normal screen colors.

null string
DELETIONS

Lines deleted found by diff.

Bright White on Red
DIRECTORIES

Directories listed by ls.

Bright
DUPLICATES

When filename completion matches more than one name.

Green
FOREIGNFILES

Filetypes in a tar file that have no counterpart on Windows.

Bright Red
HIGHLIGHT

Current disk or directory.

Bright
MATCHFAIL

When filename or command completion doesn’t match anything.

Bright Red
MOREEOF

End or Top of File in more.

Green
MOREERROR

Unrecognizable command to more.

Bright White on Red
MOREFILLIN

User response to more prompt.

Black
MOREPROMPT

Prompt line in more.

Red on White
MORETOPMEM

Top of Memory message from more.

Bright Yellow
READONLYDIRS

Directories marked read-only.

Same as DIRECTORIES

READONLYFILES

Files marked read-only.

Same as COLORS

SYSTEMDIRS

Directories with the System bit on.

Bright Green
SYSTEMFILES

Files with the System bit on.

Green

You can choose any color combinations you like from the following set: black, red, green, yellow, blue, magenta (or blue red), cyan (or blue green) and white.

Foreground or background colors may also be bright, dim (meaning simply, “not bright”) or reverse. The keyword on introduces background colors. Yellow is a true yellow only if it’s bright. (This is a system limitation not related to the C shell.)

The names of the colors and the keywords bright, dim, reverse and on are not case sensitive and may be typed in any combination of upper or lower case characters. The names of the environmental variables themselves may also be mixed case.

If a foreground or background color is left unspecified, that plane is considered transparent and inherits the color underneath it. If COLORS is null, the C shell and the utilities use the screen colors they find at startup. Setting COLORS=none turns off all use of colors except in diff and more, which have modes that aren’t sensible without colors.

You can set the colors either from within the C shell itself by simply typing the appropriate setenv statements or by including them in your login.csh or startup.csh file.

These settings can also be made through the Control Panel’s System applet.

Initial current directories

The login.csh file is also a convenient place to set up all you initial current directories. The Start Programs menu lets you specify a particular current disk and directory but not what your current directories are on the other disks when you start up; the current directories on those other disks are always \. Generally, people find it convenient to be able to choose something else and they do this by putting the appropriate cd statements in login.csh.

The final use for login.csh is in setting up certain local variables that you want different in the login shell. For example, a login shell normally dumps a history list when it exits; you may want to turn this off by setting savehist = 0. Also, you may not want an end-of-file (from accidentally hitting Ctrl-Z too many times) to cause the shell to exit; you can tell to insist on an exit statement by setting ignoreeof = 1.

Change directory behavior

If your background is Windows, you’ll probably want cd to just report the current directory if you don’t give it an argument. Those with a UNIX background may want it to mean “change to the home disk and directory.” That’s determined with the cdhome variable; the default is a Windows-style reporting only.

Another customization you may to do is to intercept cd so that you can capture your last current directory whenever you change directories:

proc cd(dest) # Capture the last working directory @ lwd = cwd if ($dest == "") then chdir else chdir $dest end end

Berkeley-style history and escapes

Also, if your fingers learned to use the !-n style of history references on a Berkeley UNIX system, you’ll want to set bsdhistory = 1. True die-hard (and perhaps daring) former UNIX users may want try setting the escapesym back to a backslash; it’ll work with the C shell but you’re on your own with other applications or tools.

Berkeley compatibility mode

Hamilton C shell does implement a substantial number of significant improvements over the original Berkeley C shell. By and large, we expect most users to find these changes welcome. But if you’re trying to run a script developed using the Berkeley C shell or if you simply want get a more precise “Berkeley mode” interactively, you can do that.

Following a common convention on Unix that the first line of a script can identify the language processor to be used with it, if the C shell encounters a script that starts with either of the following lines:

#!/bin/csh #!/usr/bin/csh

it will shift to a fairly precise emulation of the original Berkeley C shell.

To enter this mode for interactive work, start the C shell with the -B (Berkeley compatibility) option.

For more details on differences between the Hamilton and Berkeley C shells and on Berkeley compatibility mode, please refer to the Compatibility section.

Error handling

ignoreerrors, ignorestatus, noclobber, nonomatch and nullwords let you tailor how the shell responds to various exception situations. They let you determine whether you think certain things are errors. For example, should a child process that returns a non-zero return code but otherwise seems to run okay be considered an error? If you set ignorestatus = 0, it will be. Similarly, noclobber lets you intercept accidental attempts to overwrite an existing file with i/o redirection. nonomatch tells what should happen if wildcarding doesn’t match anything. nullwords tells whether you think it’s an error to use a subscript that’s off the end of an array.

Calling the C shell from other applications

Many applications, e.g., editors, make utilities and so on, depend on being able to call up the command processor. For example, make uses cmd.exe to actually process each command in the make file that it determines should be run. Most editors (and many other applications) provide a way of temporarily suspending themselves and invoking cmd.exe so you can run a few commands and then exit to return back to the editor.

Usually, these applications look at the COMSPEC environmental variable to determine the full pathname for cmd.exe (or command.com under Windows 9x). If, like nmake, they’re just calling it with a single command on the command line, they’ll probably use the cmd.exe /C option.

If you’d like to use the C shell instead of cmd.exe with these applications, set COMSPEC to point to the C shell instead and use the CSHOPTIONS environmental variable to tell the C shell to interpret the /C option flag in a way that’s compatible with the meaning cmd.exe would attach to it:

setenv COMSPEC = D:\Program Files\Hamilton C shell 2012 x64\Bin\csh.exe setenv CSHOPTIONS = -X

When the C shell starts up, if it discovers that COMSPEC points to itself, it will look through the search path to find the real cmd.exe. This is to make sure it will still be able to run .cmd files. Since the -X option is a toggling option, you can still get at the original meaning of the -C option by typing -XC to toggle back.

See also

Login.csh
Customizing the shell
C shell command line options
Aliases
Predefined aliases
Procedures
Tutorial: Aliases
Tutorial:Procedures

Previous | Next

Installation folder

You can choose where the C shell is installed and whether it's for everyone, meaning it'll appear in the Start menus for all users, or just for yourself.

Hamilton C shell distribution directory contents

During installation, a Hamilton C shell group is created in the Start menu with shortcuts to open a local copy of this User Guide and for starting the C shell. Another shortcut to the C shell is created on the desktop. Notice that multiple versions can be installed side-by-side.

Hamilton C shell shortcut properties

The shortcuts invoke the C shell as csh -L. The -L option starts the C shell as a "login" shell, causing it to look for a login.csh file. That in turn causes the C shell set up its PATH variable so it can find its Bin and Samples directories.

Hamilton C shell shortcut properties layout tab

The C shell opens in in a 25 lines x 80 characters window into a 1000 lines x 80 characters buffer. This can be changed to anything you like.

Hamilton C shell shortcut properties colors tab

The window opens with white characters on a blue background. This also can be changed to anything you like.