Many other trigger scripts have been published/donated/etc. to the ClearCase community. Why am I publishing these? Basically, because they aspire to a standard that few of the others I've seen do. Here are the design criteria which (I believe) all the following trigger scripts meet:

• They're designed to work on all ClearCase platforms, Unix and Windows.
• They work in dynamic and snapshot views.
• They're tested in GUI and command line environments.
• They do everything possible to stay in-process, meaning that they use OS interfaces to manipulate files directly rather than calling out to system utilities. This is important for performance, for portability, and for reliability.
• They're written as a family, meaning they share common coding conventions and prefix logic.
• They attempt to anticipate uncommon scenarios, such as the user not having cleartool in his/her PATH (which can happen in cron jobs or when root needs to run CC operations).

Note: I do not use or recommend ccperl, because it's both old and broken. Some of the following scripts may work with ccperl out of the box or with minor modifications, but they are tested only with a modern (~5.6.0) version of Perl. See my Perl interop page for discussion of how to set up preferred alternatives to ccperl. Where I have reason to think a script will work with ccperl I've placed a comment to that effect.

ClearCase 6.0 (aka 2003.06.00) has a more modern ccperl build based on 5.6.1. Therefore, if you're at this version or newer many of the criticisms of ccperl are obsolete. However, I'd still argue that managing your own Perl installation is more sensible in the long term; it's easier to upgrade, to install your own modules, to use on systems which don't have ClearCase installed, etc. In the following, the word "ccperl" should be understood to mean the old, 5.001-based version present in ClearCase 5.0 and below.

Remove /0 branch at uncheckout

The uncheckout_post trigger script is a standard. It removes the initial (/0) version of a branch during an uncheckout event iff the zero version is (a) the only remaining version on its branch and (b) unlabeled. Unlike most of its type, however, it works in both dynamic and snapshot views and on UNIX or Windows.

Enforce metadata naming conventions

This is another classic. It's standard CC practice to require that labels have UPPERCASE names and branches have lowercase names. This mktype_pre trigger script enforces that and for good measure adds the requirement that attributes be mixed-case.

Some people relax this restriction such that labels must only start with a capital letter, or must not be all lowercase. The script is easily modified to do this too.

Prevent "evil twins"

Yet another old standby. The mkelem_pre trigger script prevents so-called evil twins, two different elements by the same name occupying different versions of the same directory. This version has an additional feature: by default, it refuses to allow two elements whose names differ only by case to inhabit the same directory version. Though this is perfectly legal on UNIX it would cause great confusion if the VOB was ever tagged and mounted on Windows.

Standardize permissions and element modes

The mkelem_post trigger script sets the ownerships of all new elements to that of the VOB owner. This has many benefits: it makes rmelem/rmver/etc triggers unnecessary, it ensures that elements will never be owned by someone who's left the organization, it imposes consistent rights across the entire VOB, makes ls -l listings cleaner, etc.

This trigger also has code to ensure that scripts are marked executable. This sin't so much a problem on UNIX, as the view-private file from which the element is made will probably have the right perms. However, it saves a lot of trouble on Windows where the concept of an execute bit doesn't exist in native filesystems but does (and is important) in ClearCase.

Some people write this trigger to make an element inherit its ownership from its initial parent directory. This is more elegant but requires an extra cleartool operation (at least on Windows) and is therefore slower. Most organizations don't need this feature; they're happy for all VOBs and all elements within them to have the same owner, so for now my script hardwires the username by which elements should be owned.

Note: this script uses ClearCase::ClearPrompt which in turn requires Perl 5.004+ so it will not work with ccperl as is. It can, however, be adapted to ccperl by simply removing the use ClearCase::ClearPrompt; line.

File removal behavior modification

The rmname_pre trigger script refuses to allow an element to be rmnamed while it's checked out, because naive users often go out of their way to check out a file before removing it. This trigger is really a teaching tool, the lesson being that rmname is not an operation on the file but on the containing directory. Should work with ccperl.

Element grouping

The elem_group trigger script defines an element group, a set of VOB files considered a unit that generally need to be checked out and in together. Each element group has a leader and some number of followers. When the group leader is checked out, checked in, or un-checked out, the followers will get the same treatment automatically. If the user attempts to operate on a follower directly, a warning is given but the operation is still allowed.

Attach Change Request Attribute

The checkin_post trigger script prompts at checkin time for a change request number or numbers. It works on cmd lines and in GUI's, on UNIX and Windows, but not in the CC web interface. This script demonstrates the use of trigger series support from ClearCase::Clearprompt. Prompting can be suppressed entirely by setting an environment variable.