The name tcsh stands for "The C SHell". In theory, tcsh embodies more syntax elements borrowed from the C programming language.

If you’re very interested in the differences between bash and tcsch, this discussion highlighting the differences is quite detailed. Or maybe this classic discussion will be interesting to you.

The C shell theoretically makes C programmers happy by making it easy to do things the C way. I’m not 100% sure about that.

.cshrc

Note that it is .cshrc and not .tcshrc.

Set environment variables.

setenv QTDIR /usr/lib/qt4
setenv CVS_AUTH_PORT 2401
setenv CVSHOME ':ext:xed@cvs.example.com:/cvsroot'
setenv CVS_RSH      ssh
setenv EDITOR      /bin/vim

Path

Here’s how to set the path the way you want it.

set path = ( $path ~/bin ~/special . /usr/local/bin/ )

Prompt

Here’s Ruben’s.

set prompt="%m:%C9> "

Aliases

Here is the simple case.

alias v ls -l
alias mycvs 'cvs -d $CVSHOME '

Here’s one of Ruben’s that’s illustrative.

alias mksmall 'convert -size 200x200 \!* -resize 200x200 \!*:r_small.png'

If you need much more complex stuff, this is a good resource.

Branching

This is quite mysterious.

$ if ( { /bin/true } == 1 ) then ; echo "cool" ; endif
cool
$ if ( { /bin/false } == 1 ) then ; echo "cool" ; endif
if?
if? endif
cool
$

I don’t know why it would ask cryptic questions. And then if I type endif somehow the condition is true? That makes no sense.

Writability

For whatever reason, we have an environment where home directories are not writable. Don’t ask. It would be good if the .cshrc could detect that. This is easily done in bash, but in tcsh there has been much trouble leading me to this saga and questionable solution.

# Change to a writable location if /home/ is unwritable:
# Here is Chris Edwards' very simple Bash version:
# if [ ! -w ${HOME} ]; then cd /aux/${USER}; export HOME=/aux/${USER} ; fi

# From the tcsh man page:
#   If the shell is compiled with POSIX  defined  (see  the  version
#   shell variable), the result of a file inquiry is based on the
#   permission bits of the file and not on the result of the access(2)
#   system call. For example, if one tests a file with -w whose
#   permissions would ordinarily allow writing but which is on a file
#   system mounted read-only, the test will succeed in a POSIX shell
#   but fail in a non-POSIX shell.

#  File  inquiry operators can also be evaluated with the filetest
#  builtin command (q.v.) (+).

# This results in something like this:
#   [xed@c-ablab ~]$ filetest -w /home/xed/testy/a
#   1
#   [xed@c-ablab ~]$ touch /home/xed/testy/a
#   touch: cannot touch `/home/xed/testy/a': Permission denied

# This does not work:
# cat /proc/mounts | grep ^fs:.*users | awk '{print $4}' | awk 'BEGIN{FS=","}{print $1}'
# Because the directory in question is _mounted_ rw. Grr.

# Check out `man 2 access`.

# Here's a way that "works". Test for the successful exit code of:
#   bash -c test -w /home/xed

# These don't work:
#if ( ! -w ${HOME} ) then
#if ( { bash -c test -w /home/xed } ) then

echo "Checking for unwritability."
set w=`bash -c "test -w /aux/xed && echo WRITABLE"`

if ( $w == "WRITABLE" ) then
   cd /aux/${USER}
   setenv HOME /aux/${USER}
   echo "Home directory changed to /aux/${USER}..."
endif