This type of setup can cause many problems. First of all, a user might not be your exclusive user. That user might be involved with other development environments that contradict the way your environment might be setup. It also means trusting the users to change their own files to your specifications, and if you decide that there must be a change in your user's environment, then you will have to get this information to all the users, and verify each user made the change. For example, there is a ClearCase environment variable called CCASE_BLD_UMASK. This variable specifies the UMASK for derived objects. In most ClearCase installations this variable is set to "002" to allow users to change the derived objects. If you forgot to tell your users to set this variable, then when a user winks in a Derived Object from another user's view, that Derived Object is read only. If a user tries to rebuild that object file, then their build will fail.

In order to solve this problem, you decide that all users have to now set CCASE_BLD_UMASK to "002". This would now have to be done for all users. Not only that, but this also has to be done for any new user. If you have a fairly small development team of ten to twelve users, this task could take a week or two. If you have 40 or more developers, getting all of the users to change their .profile or .login scripts would become impossible.

Setting up a Standard User Environment

This special environment file should not be sourced into the current user's environment. Doing that would make it impossible for the user to restore their original environment and do other work not related to the project. Instead, a sub-shell should be set at the end of your environment script.

Selecting a Unix Shell for the Development Environment

There are two basic shell styles in Unix: The C-Shell environments that include csh, and the Turbo-C shell, and the Bourne based environment that include the Bourne, the BASH, the Kornshell, and the Posix shell. The original Unix shell is the Bourne shell developed at AT&T. It provided good programability, and became the standard shell for Unix adminstration scripts. The Csh was developed by Berkeley to take care of some of the deficiencies of the Bourne shell. This included adding command history editing, command aliasing, and shell file name completion. Other added functions including preventing accidental logging out when a CNTL-D was recieved (a common problem in the slow, noisy modem days).

Unfortunately, the syntax for the shell was completely rewritten making it incompatible with most of the established shell scripts. Not only was the syntax changed, but the Csh programming environment is buggy and not as well documented.

For years, most Unix people prefered to program shell scripts in Bourne shell, but use Csh as their environment shell. This allowed them to enjoy the features of the Bourne programming environment, but have the features found in Csh. In 1978, David Korn at AT&T developed a new shell based upon the Bourne shell that kept the standard Bourne shell syntax, but added and improved upon the features found in the Csh. Many users quickly switched to the Kornshell as their default enviroment. Some users, mainly on SunOS which refused to license the Kornshell, kept using the Csh.

My personal preference in ClearCase is stanrdizing on the Kornshell environment. The actual Kornshell is licensed on almost all Unix platforms including Sun (Solaris). In Unix platforms that do not have the actual Kornshell, the Public Domain Kornshell is available. Kornshell does all the must haves that are in Csh, and does them better (not personal opinion, but fact). Kornshell syntax is based upon Bourne shell, and almost all Bourne shell programs run easily under Kornshell. Also, the standard Posix shell is based upon Kornshell, and the default Motif shell is the Desktop Kornshell. The Kornshell "select" syntax works out great when using ClearStart, and Kornshell is more efficient and faster than Bourne shell. However, the ability in Kornshell to define your environment file (instead of having an assumed default) makes it the winner when setting up a ClearCase environment.

I use two environment files in the ClearCase environment. The first is an executable Kornshell script called env that sits in the ClearCase Administrator's HOME directory. When this shell script is executed by the user, the script sets all environment variables needed for the ClearCase environment including PATH, MANPATH, and the special ClearCase environment variables. At the end of the env, a new Kornshell is envoked, and the environment file that contains the definitions for all the shell functions and aliases is set as the default environment. Whenever a user sets a view, the user's ClearCase environment file is automatically set. This feature is not easily available in other shells. In Csh, it is impossible to redefine the .cshrc file. In BASH, you must invoke bash -posix to get the same behavior, and in Zsh, you must redefine ZDOTROOT, and fiddle around with the file names. Below is a commented version of the standard env and environment files that I do use.

As a ClearCase administrator for an entire site, I may be administering ClearCase for several separate projects. Some of these projects might be part of the same department, so they share the license server and the ClearCase Registry too. Over the years, I have come up with a standardized way of defining the ClearCase environment and I attempt to use the same basic files over and over again. Much of this file is fairly automated. I might need to change one or two things which I place at the beginning of this file for this purpose.

Notice the #! /bin/ksh on the top. Most computers now can understand that this should be run under the Kornshell. However, you might have to specify /usr/local/bin/ksh or /usr/contrib/ksh or some other location depending upon your system. Some really brain dead C shells might still not recognize the "#!" magic symbol. If you have such a system, you might try replacing the "#!" with this:

: if [ "$RANDOM" = "$RANDOM" ] then exec ksh $* fi

This is the old hack that was needed for certain computer systems. All C shells will execute a shell script in Bourne shell if the first line in the file is a colon. In Kornshell, the $RANDOM variable will change each time it is used. So, in Kornshell $RANDOM will never equal $RANDOM. However, in Bourne shell, $RANDOM isn't usually defined, and if it is defined, the value won't change while the if statement is being executed. This almost guarantees that this script will be executed in Kornshell.

The CCENV_PROJ variable is the only line that changes each time I use this file. I prefer to have CCENV_PROJ the same as the ClearCase Administrator user's ID. For example, this would be the TEK project, and the ClearCase Administrator for the TEK project is user "tek" who is also the owner of all the VOBs.

A user to set the ClearCase environment for this project would type in the following:

$ ~tek/env

This is usually pretty easy for most users to remember. However, many Bourne shells do not recognize the ~user syntax. For these users, they might have to type something like this:

$ /home/tek/env

However, considering that a Bourne shell user could easily use the Kornshell without the user even knowing it, I would recommend that you simply switch users from Bourne to Kornshell as their default shell. In fact, many operating systems now simply make /bin/sh a link to /bin/ksh.

I normally have the machine that I am using for the View Server to be the system where the ClearCase Administrator's HOME account is located. The CCENV_VIEWDIR variable is use by the .default file in ClearStart to store all of my user's views. If you have a lot of users, it might be impractical to store all of the views in a single location. In that case, you might need to expand the following line a bit so users are evenly divided between different systems.

Never, never allow views to be stored under the user's HOME directory.

The following two lines set the CCENV_HOME directory to the directory where this file is located.

I normally place all of my ClearCase shell and Perl scripts that users should have access to under $CCENV_HOME/bin. However, there are times when you might use a binary like less or even a shell or Perl script will differ from system to system due to OS issues. I place these files under the directory $CCENV_HOME/bin/<os> the binaries and scripts that differ from system to system. The following is used to find out if I am executing Solaris or SunOS. This has to be modified depending upon whatever machines you tend to run into. Unfortunately, there is no easy way around this issue.

I have found that this is the best way to set a PATH in Unix. It is clear what you are setting, it is obvious if you are setting the same directory twice in your PATH, but best of all, doing it this way makes it easy to change the way you set your PATH when necessary.

If you also use ClearDDTs, you also should include it in this PATH.

Again, I'll make the argument to use the Kornshell as the sole ClearCase environment shell. Even Sun includes the Kornshell in their release. I use to try to emulate much of what I do in this environment file in C shell, but maintaining two separate shell environments took too much time. Besides, you simply cannot match what I do in the env and environment files feature for feature with C shell.

If a user really starts to whine about not being able to use C shell (and I've only had two users who insisted on using C shell or Turbo C shell), give them a copy of the env and environment file, and tell them if they can rewrite this into C shell, and promise to maintain it, they can use C shell. No one has ever taken me up on that offer.

For a while, I tried installing ClearCase as a link install. That way, I could modify certain text configuration files in one location. However, when it came time to upgrade ClearCase, I've found problems with that type of installation. I was stuck upgrading each and every system at once whenever I installed a new version of ClearCase.

It is much easier to change these environment variables. For example, if you have to modify the xclearcase interface, you can prefix the GRP_PATH environment variable with $CCENV_HOME/grp, copy the grp file you want to change there, and modify the group file under the $CCENV_HOME/grp directory.

A controversy erupted recently on the ClearCase International User Group's mailing list about the MAGIC_PATH environment variable. It is possible for a user to redefine it, and posibly override your site's policy. I recommend that you at least put a trigger on the chtype command and the mkelem command to mail you whenever a user creates a new element, or changes the element's type. This will allow you to make sure that users are not overriding your element type policy.

In places with really tight security, you may want use a trigger to verify that MAGIC_PATH had not been changed when a user does a cleartool mkelem.

For a project, I create a single AdminVOB (I can't think for a reason why you might want more than one) and have all VOBs in the project point to this AdminVOB. This script uses the hyperlinks to find all the VOBs that user the current AdminVOB, and places them into $CLEARCASE_AVOBS.

There is also a very simple rule when it comes to Kornshell environment files: The $ENV file should not print out anything to STDERR or STDOUT, and should not append or prepend any environment variables.

I have found it easier to set the PATH, and the view's name in the ClearCase prompt. That way, a user can easily tell whether they are in a view, and which view (in case they are working in several views). I also include the project's name in the prompt because many users work in multiple projects. This makes the prompt quite long (especially with the ClearStart view tags) and I have now been placing the prompt on two separate lines.

Much of this information might work better in the Window title, and that might make the prompt fit on a single line. However, I've noticed that most users don't notice the Window's titlebar, so I still prefer the extra long prompt.

I like the name of my machine and user on the titlebar of my window. However, if you rlogin or su to another system, and then exit that system, the titlebar didn't get changed. By defining these two functions, I fix that problem

Almost all of these simply remove the need for typing cleartool each time you want to execute the ClearCase command. The clearcase_tutor and the clearcase_help commands make it easier for users to access the hyperhelp program.

One of my favorite tricks. Simply type "DEBUG" at the Unix prompt, then any shell script that starts with "#! /bin/ksh" will automatically print out debugging information. To stop, simply type "UNDEBUG" at the Unix prompt. Makes it very easy to debug Kornshell scripts.

I hate doing this, but I guess if I was a user, I wouldn't want someone changing my shell settings either. I save the user's Kornshell Environment file and will source that in after I finish setting the ClearCase environment. This will allow me to reset the user's settings like using Emacs shell history editing instead of VI shell history editing, or some of the user's prefered aliases.