Unix Admin Tips

This is just a collection of miscellaneous tips for Unix Admins (and for users like me who just like adminstering their own accounts).

Which Kind of Binary Should I Use?

I have my own personal bin directory --- or actually, four of them: one for SunOS binaries, one for Solaris binaries, one for HP binaries, and one for IBM binaries. So, my cshrc has to decide which bin-directory to use.

Here's a reasonable solution:

    if ($?BIN_TYPE == 0) then
        setenv BIN_TYPE `uname -s`_`uname -r`
        setenv BIN_TYPE `echo $BIN_TYPE | sed -e 's@[-.]@_@g'`
    endif

This code sets an environment variable BIN_TYPE, which includes the OS name and version, eg, SunOS_4_1_3. You can use $BIN_TYPE in your path, and in your compile commands:

    setenv PATH ${HOME}/bin/${BIN_TYPE}:...

    gcc -D$BIN_TYPE file.c

Because you can use it in compile commands, it's as useful for writing Makefiles as it is for configuring your cshrc.

Is This an Interactive Shell?

You put this little trick in your cshrc, to decide if the shell is interactive or not.

    setenv INTERACTIVE 0
    if (($?prompt) && { tty -s }) setenv INTERACTIVE 1

This is useful because there are lots of things you should only do if the shell is interactive. Note: if you leave out the $?prompt, condition, it will think that shell-scripts are interactive. If you leave-out the tty -s condition, it will think that rsh jobs are interactive.

In particular, the stty command, set mail command, and set prompt command should only be executed in interactive shells. Running them in other shells will occasionally cause trouble.

Set PATH in Login or Cshrc?

One of the first things your startup scripts have to do is set the PATH. Until the PATH is set, nothing else really works right.

Unfortunately, if you set the PATH in your login file, then rsh doesn't work right, because rsh doesn't run your login file. On the other hand, if you set the PATH in your cshrc, then nothing in the login file works right, because the login is executed before the cshrc. A mighty dilemma, indeed.

The solution is to avoid the login file altogether --- it's a pointless file anyway, there's no reason for it's existence. Just put all your startup commands in the cshrc. Of course, you should only do those commands at startup time. Here is a test to see whether or not the shell is a startup shell:

    if ($?NEWENV == 0) then
        setenv NEWENV 1
    else
        setenv NEWENV 0
    endif

If the NEWENV variable is 1, then the shell is a startup shell. You can use the variable to decide whether or not to perform your startup commands. It may also be wise to make some of your startup commands contingent upon whether or not the shell is interactive. (A shell started by rsh, for example, is a non-interactive startup shell.)

What's the Host Name?

Some operating systems use a program called hostname to get the current host-name, others use uname. Worse yet, some sysadmins decide to return the information in long-form like charm.cs.uiuc.edu, other decide to return it in short-form like charm. Here's some code which will get the short form of the host-name reliably:

if (($?HOST_LONG == 0)||($?HOST_SHORT == 0)) then
    if (-f /bin/hostname) set host=`hostname`
    if (($?host == 0)&&(-f /usr/bin/uname)) set host=`uname -n`
    setenv HOST_LONG $host
    set host=$host:r
    set host=$host:r
    set host=$host:r
    set host=$host:r
    setenv HOST_SHORT $host
    unset host
endif

It also gets the long hostname, if possible. The two values are returned in the environment variables HOST_LONG and HOST_SHORT.

Which Network am I On?

Sometimes, you need to know which network you are on. For example, often, a sysadmin will mess up the installation of some software, and you'll have to include some bugfix in your cshrc, which should only be executed if you're on one of the broken machines. Here's some code that helps to identify which network you are on:

if ($?FILE_SERVER == 0) then
    if (-e /etc/mtab)   set mtab=/etc/mtab
    if (-e /etc/mnttab) set mtab=/etc/mnttab
    if ($?mtab) then
      set truehome=`(cd $HOME; pwd)`
      set awk1='if (substr("'$HOME'",1,length($2)+1) == $2"/")'
      set awk2=' {for (i=1; i<length($1); i=i+1)'
      set awk3='   if (substr($1,i,1) == ":") {print substr($1,1,i-1); break;}'
      set awk4='  if (i==length($1)) print "'$HOST_SHORT'"; }'
      setenv FILE_SERVER `awk "{ $awk1 $awk2 $awk3 $awk4 }" $mtab | tail -1`
      unset mnt truehome awk1 awk2 awk3 awk4 mtab
      if (x$FILE_SERVER == x) setenv FILE_SERVER $HOST_SHORT
    else
      setenv FILE_SERVER $HOST_SHORT
    endif
endif

Careful, you need the hostname trick (see previous section) for this to work. This code returns the name of the machine which is storing your home directory in an environment variable FILE_SERVER. That's usually sufficient to identify which network you are on.

X in a Box

This is a great trick to make X Windows a little more convenient. You write a single 'sh' script that starts up X Windows and hardwires everything: the initial clients, the background colors, the window manager. The script should pay no attention whatsoever to any configuration files like xinitrc or anything else in your directory, it should control absolutely everything entirely by itself.

This way of doing things is very convenient for sysadmins and novice users: the sysadmin installs the script in a bin-directory somewhere. Novice users just run the script, and boom, it starts X in a reasonable configuration, with no fuss, and no questions asked.

If you ever borrow a friend's account, you've been aggravated by the fact that his window manager doesn't use the same keystrokes as yours. If you use an script like this, though, you can give your friend a copy of your script, which you can run when you're using his computer. It'll have your favorite ``look and feel'', even though it's his account.