COFLAGS
macro, the project directory must be "clean." For example, if the wrong
version of a .cc file is already present in the project
directory, make will not check out the proper version because
both version have the same file name and make has no way to tell
the difference. You can add this rule to your Makefile so that "make
clean" will leave you with a clean project directory:
clean :
<tab> rcsclean
<tab> -ci $(SRCS) $(MANS) Makefile > /dev/zero
<tab> rm -f core *.o $(PROGS)
<tab> -rm -i *.cc *.1 *.h
The rcsclean command causes rcs to delete any files that are
checked out without locks, provided they are from the latest revision.
The ci command checks any file that are locked back in. If
there are no locked files, this command will fail, so the ci
command is prepended with a '-', which tells make to ignore any
errors that result from executing this command. The standard output
for this command is redirected to /dev/zero (a
pseudo-device that accepts and discards anything sent to it) to reduce
screen clutter. The first rm command gets rid of files that can
always be recreated if needed; the "-f" option makes the
command force removal of files that are read-only without asking you if
it is all right. This can be dangerous, so the last command forces
rm to ask you if it is all right to delete any man pages or
source files that are still in the project directory. Again, this
command might fail (if there are no .cc, .1,
or .h files), so the command is prepended with a '-'.
The SRCS, HDRS, MANS, and
PROGS macros should be set to lists of the
.cc, .h, .1 and .3,
and executable files for the project, respectively.
Check in your new Makefile.
You aren't going to change ou for this use case, but you need to
have copies of ou.cc and ou.1 with a revision
level of 2. Use the following sequence of commands:
% co -l ou.cc ou.1
% ci -f -r2 ou.cc ou.1
Check the the handout page on
Using RCS for more information if this isn't clear.
You will also need a copy of Makefile with a revision level
of 2, so you should create that now.
argv[0]) with
.log appended to it. When om starts running it
writes a line to this file with the current date and time and the name
of the host on which it is running.Each time om receives a datagram, it writes it to the log file, along with a timestamp and the name of the host that it was sent from. Also, when a value is returned to a client, write that datagram to the log file too.
For example, om running on babbage might generate a log file that looks like this:
Tue Dec 9 22:24:39 1997: Object Manager om started on host babbage
Tue Dec 9 22:25:14 1997: Request from babbage: listClasses
Tue Dec 9 22:25:14 1997: Reply to babbage: "alpha:beta"
Tue Dec 9 22:25:14 1997: Request from babbage: bad command
Tue Dec 9 22:25:14 1997: Reply to babbage: "*** invalid request ***"
Tue Dec 9 22:26:26 1997: Request from babbage: exit normal shutdown
Tue Dec 9 22:26:26 1997: Exiting: normal shutdown
In this example, the third line shows the names of the classes given on
the om command line separated by ':', but your list might be
separated by newlines. The last line was generated by in response to
the exit command, but nothing was sent back to the client.Be sure each line in the log file can be read by a user as soon as it is written. If you write to a buffered output file (by using fwrite(), printf(), or fprintf(), you will have to flush the output buffer every time you write to the file. Alternatively, you can use write() to send messages to the log file and you won't need to flush any buffers.
Help: You can get the time and date by using the time()
function from the standard library, and you can convert it to text for
printing by using the ctime() function. You should remove the
'\n' from the end of the string returned by ctime() so that the
timestamp and the name of the host are on the same line of the log file.
You can get the name of the remote host by using gethostbyaddr().
Pass it the struct sockaddr that was returned by
recvfrom(), and the h_name field of the struct
hostent that is returned will have the string you want.
Make sure your ou works with ~vickery/bin/om_2 and
that your om works with ~vickery/bin/ou_2
When you finish making changes to om.cc, check it in as
revision 2:
ci -r2 om.cc