Playing nicely with others

By Paul Murphy, author of The Unix Guide to Defenestration

In Unix, when something that was working fails, your immediate question should be: "what changed?" Often you'll remember having done something, but if you work in a typical Windows oriented shop where the boss insists on letting lots of people have the root password for the Unix machines that do most of the real work, you may not have a clue who did what or when.

The only way I know of to stop this is to change bosses, but there is something you can do to make it easy to find where the nit made its contributions.

Simply make yourself a script that does something like


#!/bin/csh
ls -laR /etc >~filerecs/etc.files.`date`
ls -laR /usr/local >~filerecs/lib.files.`date`
ls -laR /dbs/sybase >~filerecs/syb.files.`date`
and so on for all critical file groups


Use cron to fire it off every night and manually clean up the directory every couple of weeks -but make sure you leave some older files in place.

Then, when you get that user phone call accusing you of making SAS (or whatever) fail, you can re-run the "ls -laR" for the likeliest candidate file system, output the result to a file, and use diff or comm to tell you exactly what changed. Once you know, resetting permissions, undoing the symbolic link, or recovering the file from backup is easy.