| > This is not guaranteed to work.  This shows the danger of locks: in the
| > time between the test (File.exist?) and the creation (File.open) someone
| > else could interfere, and a lock could already be there when File.open
| > is reached.
| 
| ....And same is true when system is used.  Why can you believe a file
| existence check and a creation in the shell are atomic?

Normally, I would agree.  But the (shell) code in question is this:

   set -o noclobber
   cat /dev/null 2> /dev/null > process.lock

The real question would be in the code for the redirection operator '>'
This code would attempt to create an empty file (cat /dev/null), redirect
it to process.lock ( > process.lock), and throw away error messages
( 2> /dev/null).  Without the throw-away, one gets a message like this
if the file exists:

/usr/bin/ksh[2]: process.lock: file already exists

Without the "noclobber" option, the error does not appear, and the
existing file would be "overwritten" - which in this case of locks,
would be meaningless.

| File locking are usually implemented with atomic operations such as
| symlink or mkdir.  These operations are atomic --- an existence check
| and a creation of a named symbolic link/directory can not be interrupted
| by any process.

How would one use this?  Neither a symbolic link nor a directory would
have much use as a lock file, I would think.

| In unix-like systems, symlink is preferred since it can make a
| symbolic link to any file --- even non existent or it can not exist in
| a file system.  However if extreme portability is necessary, only
| mkdir can be candidate of lock operation.

How would you use this?  Please explain.  I really do want to know -
the true "test-and-set" of locks is not often covered.