It incorporates all the patchlets that people have sent me. It also updates
the TODO file with all the other problems I haven't had time to fix yet. There
is one more possible serious problem remaining that I want to fully investigate
(from Dirk Craeynest), which I haven't added to the TODO file yet.
The next thing I want to do (in my copious spare time), is to create a
prototype of faces with the three separate components (as discussed previously
on this list). Maybe next week...
PS: Note that I forgot to update the acknowledgements section of the faces
README file for all the new faces bug fixers. I'll do that next time.
For now, thankyou.
------
This is patch #3 for v1.5 of faces. It consists of a set of diffs to apply
to the faces source. See the installation instructions below on how to apply
this patch.
Changes made in this patch:
v1.5 - patchlevel 3 - 19th June 1991.
- Added in ANSI C function prototypes for each faces routine, and
compiled with Sun's ANSI C compiler, fixing up inconsistencies.
- From Alan Skea <skea@vast.eecs.unsw.oz.au>
We are running SunOS 4.0.3c on most of our machines and while we
have the utime() library call, we do not have a <utime.h>. If I
compile with NOUTIME defined then the utime structure that is
declared in faces.h fails because type time_t is not declared.
Needs an inclusion of <sys/types.h> in faces.h
- From Steve Kinzler <kinzler@iuvax.cs.indiana.edu>
Had to comment out the external declaration for memset() in faces.h,
to get it to compile on Ultrix 4.1.
- From Tim Chown <T.J.Chown@ecs.southampton.ac.uk>
If the mail spool shrinks (ie. the user deletes mail) then the
window should adjust; the -MH option doesn't seem to work for
me in this respect. Using -MH is a little misleading as I use
Elm and that can shrink the mail spool file too, so perhaps
the man page (and option name) should reflect this.
[Command line option has been changed from -MH to -M, and the
manual pages adjusted to reflect this - Rich.]
- From Paolo Petta <ai-vie!oefai!paolo@relay.EU.net>
Elm is our mailer of choice: At least on our system it has the
peculiarity of not erasing the system mailbox file
(/usr/spool/mail/...) but simply truncating the file to zero length.
Faces is not correctly recognising this.
- From Tim Chown <T.J.Chown@ecs.southampton.ac.uk>
The remote host monitoring wouldn't work either. This needed a
different variable rhostname to be used with -H rather than hostname
which was getting overwritten (so that localhost was always seen!).
From Dirk Craeynest <dirk@cs.kuleuven.ac.be>
`faces -H hostname' always gives information about users on the
local host.
- From Tim Chown <T.J.Chown@ecs.southampton.ac.uk>
The addition of the option -l window_label is desirable; the default
label is "faces" which is a bit nondescript.
- From Tim Chown <T.J.Chown@ecs.southampton.ac.uk>
Don't take sounds for mail when first reading in the mail spool
file. Just play them for new mail.
- From Steve Kinzler <kinzler@iuvax.cs.indiana.edu>
The following TODO entry (#1) is already implemented. I've adjusted
my faces front-end script to correctly handle arguments with white
space.
As it is now, there's no way to specify arguments for "-e"
application scripts. If we ever want to abstract things like
the -H function out of faces itself and into a script, we'll
want something like this. I can think of two possible solutions
to the problem, both extending the faces command line syntax:
1) % faces -e "who.faces iuvax"
2) % faces -e who.faces iuvax \; ala find -exec
[scripts/README.kinzler, and scripts/newscheck.faces also updated.]
- From Steve Kinzler <kinzler@iuvax.cs.indiana.edu>
Hostnames that begin with "misc." (eg, "misc.religion.talk"
in the news faces database) will end up with the misc./unknown icon
instead of the proper icon.
There may be other instances in the code of a similar bug (ie, where
strcmp should be used instead of strncmp/EQUAL).
- From Dave Cohrs <dave@cs.wisc.edu>
If you specify your beeps and flashes in a resource database, the
.mailrc reader shouldn't zero them out.
--------
How to install this patch.
You should use Larry Wall's patch program to apply these diffs. Assuming the
patch file is called faces.patch3, then you should do the following:
cd faces_src # directory where your faces source files are.
patch -p0 <faces.patch3
make x11 # Or xview, sunview or news.
make install # You might have to be super-user.
--------
Where to get this patch.
* I've put a copy of both patch #3 and the very latest fully patched version
of faces, in the pub/faces/incoming directory on iuvax.cs.indiana.edu,
for those of you who have anon ftp capabilities. Steve, could you do your
bit with these files please, and move them to the parent directory?
* For Sun employees around the world, you can get the fully patched latest
version of faces via anon ftp from stard.aus. It (and copies of the
various faces databases held by Steve on indiana) are now in a
sub-directory under pub called faces.
* For Australian sites without ftp capabilities, the latest faces.tar.Z
and those faces databases are available via fetchfile from sunaus.sun.oz.
These are also in a faces sub-directory, so fetch (depending upon your
requirements):
faces/facedir.tar.Z
faces/faces.tar.Z
faces/facesaver.tar.Z
faces/logos.tar.Z
faces/news.tar.Z
* And finally both the patch and the fully patched latest version of faces
are available via the automatic mail archive server. Requests should be
sent to rb-archive-server@Aus.Sun.COM. To just get patch #3, then the
message should contain the line:
send faces patch3
Note that this patch is a uuencoded compressed file. Unpack with uudecode
and uncompress first, before applying the installation instructions given
above.
If you want the complete fully patched version of faces v1.5.3, then you
should send fifteen messages containing the lines:
send faces partn
where n = 1-15. You can do this is one message, but the archive server
processes smaller messages faster. UUCP sites out there might like to
include a path line with each message, something like:
path uunet.uu.net!hostname!user
note that this is uunet.uu.net and not just uunet. Sun.COM doesn't
recognise uunet. This is the return path the archive server will use to
send your requests to. Also UUCP sites should note that you probably have a
size limit on each message. Yet another good reason to divide these into
multiple requests.