ROEL A. GUTAY
BSIT 4-3
201010981
PROJECT IN PROGRAMMING LANGUAGES
C SHELL

HISTORY :
The C shell (csh or the improved version, tcsh, on most machines) is aUnix shell that was created by Bill Joy while a graduate student atUniversity of California, Berkeley in the late 1970s. It has been distributed widely, beginning with the 2BSD release of the BSD Unix system that Joy began distributing in 1978. Other early contributors to the ideas or the code were Michael Ubell, Eric Allman, Mike O'Brien and Jim Kulp.
The C shell is a command processor typically run in a text window, allowing the user to type commands. The C shell can also read commands from a file, called a script. Like all Unix shells, it supports filename wildcarding, piping, here documents, command substitution,variables and control structures for condition-testing and iteration. What differentiated the C shell from others, especially in the 1980s, were its interactive features and overall style. Its new features made it easier and faster to use. The overall style of the language looked more like C and was seen as more readable.
On many systems, such as Mac OS X and Red Hat Linux, csh is actually tcsh, an improved version of csh. One file containing the tcsh executable has links to it as both "csh" and "tcsh" so that either name refers to the same improved version of the C shell.
On Debian, Ubuntu, and their derivatives, there are two different packages: csh and tcsh. The former is based on the original BSD version of csh and the latter is the improved tcsh. tcsh added filename and command completion and command line editing concepts borrowed from the Tenex system, which is the source of the "t". Because it only added functionality and did not change what was there, tcsh remained backward compatible with the original C shell. Though it started as a side branch from the original source tree Joy had created, tcsh is now the main branch for ongoing development. tcsh is very stable but new releases continue to appear roughly once a year, consisting mostly of minor bug fixes.

ADVANTAGES:
• Do you ever find that you often do a number of UNIX commands together and you would like to "bundle" them up into one name? You can do this, in effect,creating a brand new command. Other operating systems permit this convenience,most notably MS-DOS, which calls such files "BAT" or batch files. In UNIX,such a file is called a shell script.
• the C shell should be better for interactive use. It introduced numerous new features that new features proved very popular, and many of them have since been copied by other Unix shells.made it easier, faster and more friendly to use by typing commands at a terminal. Users could get things done with a lot fewer keystrokes and it ran faster. The most significant of these new features were the history and editing mechanisms, aliases, directory stacks, tilde notation, cdpath, job control and path hashing. These

• The C shell operates one line at a time. Each line is tokenized into a set of words separated by spaces or other characters with special meaning, including parentheses, piping and input/output redirection operators, semicolons, and ampersands.

DISADVANTEGES
• The Ad Hoc Parser

The biggest problem of the C shell (and TCSH) it its ad hoc parser. Now this information won't make you immediately switch shells. But it's the biggest reason to do so. Many of the other items listed are based on this problem. Perhaps I should elaborate. The parser is the code that converts the shell commands into variables, expressions, strings, etc. High-quality programs have a full-fledged parser that converts the input into tokens, verifies the tokens are in the right order, and then executes the tokens. The Bourne shell even as an option to parse a file, but don't execute anything. So you can syntax check a file without executing it.

• Multiple-line quoting difficult

The C shell complaints if strings are longer than a line. If you are typing at a terminal, and only type one quote, it's nice to have an error instead of a strange prompt. However, for shell programming - it stinks like a bloated skunk.

• Quoting can be confusing and inconsistent

The Bourne shell has three types of quotes:

"........" - only $, `, and \ are special. '.......' - Nothing is special (this includes the backslash) \. - The next character is not special (Exception: a newline)

That's it. Very few exceptions. The C shell is another matter. What works and what doesn't is no longer simple and easy to understand.

• If/while/foreach/read cannot use redirection

The Bourne shell allows complex commands to be combined with pipes. The C shell doesn't. Suppose you want to choose an argument to grep.

• Getting input a line at a time

Suppose you want to read one line from a file. This simple task is very difficult for the C shell. The C shell provides one way to read a line:

% set ans = $<

The trouble is - this ALWAYS reads from standard input. If a terminal is attached to standard input, then it reads from the terminal. If a file is attached to the script, then it reads the file.

But what do you do if you want to specify the filename in the middle of the script? You can use "head -1" to get a line. but how do you read the next line? You can create a temporary file, and read and delete the first line. How ugly and extremely inefficient. On a scale of 1 to 10, it scores -1000.

Now what if you want to read a file, and ask the user something during this? As an example - suppose you want to read a list of filenames from a pipe, and ask the user what to do with some of them? Can't do this with the C shell - $< reads from standard input. Always. The Bourne shell does allow this. Simply use

$ read ans file means stdout will be written to file, overwriting it if it exists, and creating it if it doesn't. Errors still come to the shell window.
>& file means both stdout and stderr will be written to file, overwriting it if it exists, and creating it if it doesn't.
>> file means stdout will be appended at the end of file.
>>& file means both stdout and stderr will be appended at the end of file.
< file means stdin will be read from file.
&2 Year \"$year\" out of my range exit 127 fi

etc...

# ok, you have the number of days since Jan 1, ...

case `expr $days % 7` in 0) echo Mon;; 1) echo Tue;;

etc...
Error messages should appear on stderr not on stdout! Output should appear on stdout. As for input/output dialogue: # give the fellow a chance to quit

if tty -s ; then echo This will remove all files in $* since ... echo $n Ok to procede? $c; read ans case "$ans" in n*|N*) echo File purge abandoned; exit 0 ;; esac RM="rm -rfi" else RM="rm -rf" fi
Note: this code behaves differently if there's a user to communicate with (ie. if the standard input is a tty rather than a pipe, or file, or etc. See tty(1)).
Language Constructs
For loop iteration
Substitute values for variable and perform task: for variable in word ... do command done
For example: for i in `cat $LOGS` do mv $i $i.$TODAY cp /dev/null $i chmod 664 $i done
Alternatively you may see: for variable in word ...; do command; done
• Case
Switch to statements depending on pattern match case word in [ pattern [ | pattern ... ] ) command ;; ] ... esac
For example:

case "$year" in

[0-9][0-9]) year=19${year} years=`expr $year - 1901` ;; [0-9][0-9][0-9][0-9]) years=`expr $year - 1901` ;; *) echo 1>&2 Year \"$year\" out of range ... exit 127 ;; esac
• Conditional Execution
Test exit status of command and branch if command then command [ else command ] fi
For example: if [ $# -ne 3 ]; then echo 1>&2 Usage: $0 19 Oct 91 exit 127 fi
Alternatively you may see: if command; then command; [ else command; ] fi
• While/Until Iteration
Repeat task while command returns good exit status. {while | until} command do command done
For example: # for each argument mentioned, purge that directory

while [ $# -ge 1 ]; do _purge $1 shift done
Alternatively you may see: while command; do command; done
• Variables
Variables are sequences of letters, digits, or underscores beginning with a letter or underscore. To get the contents of a variable you must prepend the name with a $.
Numeric variables (eg. like $1, etc.) are positional vari- ables for argument communication. o Variable Assignment
Assign a value to a variable by variable=value. For example: PATH=/usr/ucb:/usr/bin:/bin; export PATH or TODAY=`(set \`date\`; echo $1)` o Exporting Variables
Variables are not exported to children unless explicitly marked. # We MUST have a DISPLAY environment variable

if [ "$DISPLAY" = "" ]; then if tty -s ; then echo "DISPLAY (`hostname`:0.0)? \c"; read DISPLAY fi if [ "$DISPLAY" = "" ]; then DISPLAY=`hostname`:0.0 fi export DISPLAY fi
Likewise, for variables like the PRINTER which you want hon- ored by lpr(1). From a user's .profile: PRINTER=PostScript; export PRINTER
Note: that the Cshell exports all environment variables. o Referencing Variables
Use $variable (or, if necessary, ${variable}) to reference the value. # Most user's have a /bin of their own

if [ "$USER" != "root" ]; then PATH=$HOME/bin:$PATH else PATH=/etc:/usr/etc:$PATH fi
The braces are required for concatenation constructs.
$p_01
The value of the variable "p_01".
${p}_01
The value of the variable "p" with "_01" pasted onto the end. o Conditional Reference o ${variable-word}
If the variable has been set, use it's value, else use word.
POSTSCRIPT=${POSTSCRIPT-PostScript};
export POSTSCRIPT

${variable:-word}
If the variable has been set and is not null, use it's value, else use word.
These are useful constructions for honoring the user envi- ronment. Ie. the user of the script can override variable assignments. Cf. programs like lpr(1) honor the PRINTER environment variable, you can do the same trick with your shell scripts.
${variable:?word}
If variable is set use it's value, else print out word and exit. Useful for bailing out. o Arguments
Command line arguments to shell scripts are positional vari- ables:
$0, $1, ...
The command and arguments. With $0 the command and the rest the arguments.
$#
The number of arguments.
$*, $@
All the arguments as a blank separated string. Watch out for "$*" vs. "$@".
And, some commands: shift Shift the postional variables down one and decrement number of arguments. set arg arg ...
Set the positional variables to the argument list.
Command line parsing uses shift: # parse argument list

while [ $# -ge 1 ]; do case $1 in process arguments... esac shift done
A use of the set command: # figure out what day it is

TODAY=`(set \`date\`; echo $1)`

cd $SPOOL

for i in `cat $LOGS` do mv $i $i.$TODAY cp /dev/null $i chmod 664 $i done o Special Variables o $$
Current process id. This is very useful for constructing temporary files. tmp=/tmp/cal0$$ trap "rm -f $tmp /tmp/cal1$$ /tmp/cal2$$" trap exit 1 2 13 15 /usr/lib/calprog >$tmp

$?
The exit status of the last command. $command # Run target file if no errors and ...

if [ $? -eq 0 ] then etc... fi

• Quotes/Special Characters
Special characters to terminate words: ; & ( ) | ^ < > new-line space tab
These are for command sequences, background jobs, etc. To quote any of these use a backslash (\) or bracket with quote marks ("" or '').
Single Quotes
Within single quotes all characters are quoted -- including the backslash. The result is one word.

grep :${gid}: /etc/group | awk -F: '{print $1}'
Double Quotes
Within double quotes you have variable subsitution (ie. the dollar sign is interpreted) but no file name generation (ie. * and ? are quoted). The result is one word. if [ ! "${parent}" ]; then parent=${people}/${group}/${user} fi
Back Quotes
Back quotes mean run the command and substitute the output.

if [ "`echo -n`" = "-n" ]; then n="" c="\c" else n="-n" c="" fi and TODAY=`(set \`date\`; echo $1)`
Sample codes
The following csh code will print welcome message five times on screen: #!/bin/csh # demoloop.csh - Sample loop script set j = 1 while ( $j