Never name a file 'core'. It will probably be deleted within 7 days by a System Administrator's script.

If you do want save a core file for diagnostic purposes then rename it, eg mv core core-28112009

Be careful when using the rm -r command. You could delete more than you expected.

Be careful when using the 'action' aspects of the find command. The find command is a Unix power tool. If you use rm as the action, you could delete more than you expected. If in doubt, use the -ok action to give you an interactive prompt.

If you want to share data between processes, you must first export the variable, eg, x=5, export x. Note that the value of variable x in the parent shell cannot be updated by variable x in the child process. Nor can the value of variable x be exported back to the parent process by the child process.

Never switch off a Unix box by using the on/off switch. Any open files in the mounted file systems will become inconsistent. Next time you switch on, the system will detect these inconsistencies and force the fsck command to run against each mounted file system. This is a slow process and causes excessive down time. This will get you the type of attention from your colleagues that you really don't want. When you want to log off a box, close down all the processes and terminal sessions you have created, and use the EXIT icon on the Front Panel. It is normal for boxes to remain powered up overnight as the box is invariably attached to your local network. This allows it to receive emails and any file or code distributions overnight.

Never experiment with files in the /etc directory. These essential text configuration files are key to stable systems' maintenance. Stay out of /etc unless absolutely necessary. If you want to practice copying, moving or deleting files, create files and directories in your own home directory and test to your heart's content.

Don't manually edit files or directories in /var/adm or /var/sadm. These directories are sentive hierarchical databases used by commands like pkgadd and pkgdel. These directories should be managed by Unix commands alone.

Don't delete directories under /proc. The number eg, 1213 represents and active process and all its underlying data structures. Make sure you only use this directory as read-only.

If you want to practice creating and killing processes, that's fine. But please be careful to ensure that you only kill your own process ids and job ids. As a regular user, you can only manipulate your own processes anyway. However, as root, you can create havoc by incorrectly deleting system processes or client processes. Always take a few moments to check what you're doing.

If a user requests that you kill his processes or a client process, always be wary of such requests. The processes could be shared by a number of users who are accessing them satisfactorily. If it is a client process, always review it with your supervisor. Usually, there is a business contact who authorizes such decisions. Do not be over eager to assist in such situations. Always get clearance from your manager or the business. With the power comes the responsibility. You are not paid as a Risk Manager.

If you make a serious mistake that effects day to day operations, own up to it quickly and initiate whatever recovery action is required. Your honesty will reflect in your trustworthiness. Don't ignore it and hope that nobody will notice. It will invariably come back to haunt you. How would you feel if the finger was pointing at you for somebody else's mistake?