NAME

newcsh − description of new csh features (over oldcsh)

SYNOPSIS

csh csh-options

SUMMARY

This is a summary of new features in csh(1) in this version of the system; an older version of csh is available as oldcsh.  This newer csh has some new process control primitives and a few other new features.  Users of csh must (and automatically) use the new terminal driver (summarized in newtty(4) and completely described with the old in tty(4)) which allows generation of some new interrupt signals from the keyboard which tell jobs to stop, and arbitrates access to the terminal; on CRT’s the command “stty crt” is normally placed in the .login file to be executed at login, to set other useful modes of this terminal driver. 

Jobs. 

The most important new feature in this shell is the control of jobs.  A job is associated with each pipeline, where a pipeline is either a simple command such as “date”, or a pipeline such as “who | wc”.  The shell maintains a table of current jobs, and assigns them small integer numbers.  When you start a job in the background, the shell prints a line as follows:

    [1] 1234

This line indicates that the job which was started asynchronously with “&” is job number 1 and has one (top-level) process, with a process id of 1234.  The set of current jobs is listed by the jobs command. 

If you are running a job and wish to perform another operation, you may press the key ^Z (control-Z), which sends a stop signal to the current job.  The shell then normally indicates that the job has been “Stopped”, and prints another prompt.  You can then put the job in the background with the command “bg”, or run some other commands and return the job to the foreground with “fg”.  A ^Z takes effect immediately and is similar to an interrupt in that pending output and unread input are discarded when ^Z is typed.  There is another special key, ^Y, which does not generate a stop signal until a program attempts to read(2) it. ^Y can conveniently be typed ahead when you have prepared some commands for a job which you wish to stop after it has read them.

A job being run in the background stops if it attempts to read from the terminal.  Background jobs are normally allowed to produce output, but this can be disabled by setting “stty tostop”.  If you set this tty option, background jobs stop when they try to produce output as when they try to read input. 

There are several ways to refer to jobs in the shell.  The character “%” introduces a job name.  If you wish to refer to job number 1, you can name it “%1”.  Naming a job brings it to the foreground; thus, “%1” is a synonym for “fg %1”, and brings job 1 back into the foreground.  Similarly, entering “%1 &” resumes job 1 in the background.  Jobs can also be named by prefixes of the string typed in to start them, if these prefixes are unambiguous; thus, “%ex” normally restarts a suspended ex(1) job, if there is only one suspended job with a name which begins with the string “ex”.  It is also possible to refer to “%?string” which specifies a job with a text which contains string, if there is only one such job. 

The shell also maintains a record of the current and previous jobs.  In output pertaining to jobs, the current job is marked with a “+” and the previous job with a “−”.  The abbreviation “%+” refers to the current job and “%−” refers to the previous job.  For close analogy with the history mechanism, “%%” is also a synonym for the current job. 

Status reporting. 

This shell immediately is informed whenever a process changes state.  This shell normally informs you whenever a job becomes blocked so that no further progress is possible, but only just before it prints a prompt;  The purpose of this delay is to not disturb your work.  If, however, you set the shell variable notify, the shell notifies you immediately of changes of status in background jobs.  There is also a shell command notify which marks a single process so that its status changes are immediately reported.  By default, notify marks the current process; simply enter “notify” after starting a background job to mark it. 

When you try to leave the shell while jobs are stopped, you are warned that “You have stopped jobs.”  You may use the “jobs” command to pertain what specific jobs are stopped.  If you use this command or immediately try to exit again, the shell does not give a second warning, and the suspended jobs are terminated. 

New builtin commands. 

bg

bg %job ... 
Puts the current or specified jobs into the background, continuing them if they were stopped.

fg

fg %job ... 
Brings the current or specified jobs into the foreground, continuing them if they were stopped.

jobs

jobs −l
Lists the active jobs; if given the −l options, lists process id’s in addition to normal information. 

kill %job

kill −sig %job ... 

kill pid

kill −sig pid ... 

kill −l
Sends either the TERM (terminate) or specified signal to the specified jobs or processes. Signals are given either by number or names (as given in /usr/include/signal.h, stripped of the prefix “SIG”).  The signal names are listed by “kill −l”.  There is no default; only entering ‘kill’ does not send a signal to the current job.  If the signal being sent is TERM (terminate) or HUP (hangup), the job or process is also sent a CONT (continue) signal. 

notify

notify %job ... 
Causes the shell to notify the user asynchronously when the status of the current or specified jobs changes; normally, notification is presented before a prompt.  All jobs are marked “notify” if the shell variable “notify” is set.

stop %job ... 
Stops the specified job which is executing in the background.

%job
Brings the specified job into the foreground.

%job &
Continues the specified job in the background.

Process limitations. 

The shell provides access to an experimental facility for limiting the consumption by a single process of system resources.  The following commands control this facility:

limit resource maximum-use

limit resource

limit
Limits the consumption by the current process, and each process it creates, to not individually exceed maximum-use on the specified resource.  If no maximum-use is given, the current limit is printed; if no resource is given, all limitations are given. 

Resources controllable currently include cputime (the maximum number of cpu-seconds to be used by each process), filesize (the largest single file which can be created), datasize (the maximum growth of the data+stack region via sbrk(2) beyond the end of the program text), stacksize (the maximum size of the automatically-extended stack region), and coredumpsize (the size of the largest core dump that will be created). 

The maximum-use may be given as a floating point or integer number followed by a scale factor.  For all limits other than cputime, the default scale is “k” or “kilobytes” (1024 bytes); a scale factor of “m” or “megabytes” may also be used.  For cputime, the default scaling is “seconds”, “m” for minutes or “h” for hours; or a time of the form “mm:ss” giving minutes and seconds may be used. 

For both resource names and scale factors, unambiguous prefixes of the names suffice. 

unlimit resource

unlimit
Removes the limitation on resource.  If no resource is specified, all resource limitations are removed. 

Directory stack. 

This shell now maintains records of the current directory (which is stored in the variable cwd) and also maintains a stack of directories, which is printed by the command dirs.  You can change to a new directory and push down the old directory stack by using the command pushd, which is similar to the chdir command.  You can pop the directory stack by entering popd.  Entering pushd with no arguments exchanges the top two elements of the directory stack.  The elements of the directory stack are numbered from 1, starting at the top.  Entering pushd with argument “+n” rotates the directory stack and causes that entry to be at the top in the stack.  Giving popd a “+n” argument eliminates that argument from the directory stack. 

Miscellaneous. 

This shell imports the environment variable USER into the variable user, TERM into term, and HOME into home, and exports these variables back into the environment whenever the normal shell variables are reset.  The environment variable PATH is identically handled; it does set other than in the file .cshrc, as inferior csh processes import the definition of path from the environment, and re-export it if you then change it.  (Path could be set once in the .login, except commands over the Berknet would not see the definition.) 

There are new commands, eval, which is similar to the eval of the Bourne shell sh(1), and useful with tset(1), and suspend, which stops a shell identically to ^Z.  As shells normally ignore ^Z signals, this command is necessary. 

There is a new variable, cdpath; if set, each directory in cdpath is searched for a directory named in a chdir command, if there is no such subdirectory of the current directory. 

An unsetenv command removing environment variables has been added. 

There is a new “:” modifier, “:e”, which yields the extension portion of a filename;  thus, if “$a” is “file.c”, “$a:e” is “c”. 

There are two new operators in shell expressions, “!~” and “=~”, which are similar to the string operations “!=” and “==”, except that the right hand side is a pattern (e.g., containing “\(**”s, “?”s and instances of “[...]”) which the left hand operand is matched against.  These operations reduce the need for the switch statement in shell scripts when only pattern matching is required. 

The form “$<” is new, and is replaced by a line from the standard input, with no further interpretation thereafter;  It may therefore be used to read from the keyboard in a shell script. 

SEE ALSO

csh(1), killpg(2), sigsys(2), signal(2), jobs(3), sigset(3), tty(4)

BUGS

Command sequences of the form “a ; b ; c” are not handled gracefully when stopping is attempted.  If you suspend “b”, the shell will then immediately execute “c”.  This is especially noticeable if this expansion results from an alias.  It suffices to place the sequence of commands in ()’s to force it to a subshell (i.e., “( a ; b ; c )”), but see the next bug. 

Shell built-in functions are not stoppable/restartable. 

Control over output is primitive; perhaps this will inspire someone to work on a good virtual terminal interface.  In a virtual terminal interface much more interesting things could be done with output control. 

4th Berkeley Distribution  —  %W%%Q%%Y%