Subject: Binaries for SCO-UNIX

From: [email-masked]
Date: Mon, 4 Apr 1994 16:40:55 -0500 (CDT)

Hi,
 Our college has recently acquired a box running on SCO-UNIX and I was 
wondering if we could find a binary version of Pine to run on our 
machine. What are the other requirements as far as files, pathnames, etc? 
We would be extremely grateful if someone could throw some light on the 
situation.

 Thanks in advance,

Chris Fullinfaw

[email-masked]

(712)274-8733x1291

---

From: David L Miller <[email-masked]>
Date: Mon, 4 Apr 1994 15:13:19 -0700 (PDT)

Chris,

I understand there is an SCO port of pine on soils.agron.iastate.edu.  It 
is not part of the official distribution and I have heard mixed reviews 
about it, so let us know how you fare...

Thanks for the request!

--DLM

|\ |  |\/|  David L. Miller    [email-masked]  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing, JE-20
4545 15th Ave NE, Seattle WA 98105, USA

---

From: "G. H. Chinoy" <[email-masked]>
Date: Mon, 4 Apr 1994 18:01:43 -0500 (CDT)

I have a silly question.  Is there a way to make pine play a 
different beep sound than just the standard one when a new message 
arrives?  We're using NeXT machines running NeXTstep 3.0.

	Any ideas?

	Hussain Chinoy

____________________________________________________________________________
   G. Hussain Chinoy		Head Consultant, Arts & Sciences NeXT Lab
   [email-masked]	Cupples I, Room 213
				314.935.4353
				Washington University in St. Louis

---

From: David L Miller <[email-masked]>
Date: Mon, 4 Apr 1994 17:25:20 -0700 (PDT)

Hussain,

The only thing Pine currently does for a beep is send a ^G.  At some 
point we might change this, but I'm not sure how soon.

Thanks for the request!

--DLM

---

From: James Dryfoos <[email-masked]>
Date: Tue, 5 Apr 94 09:51:21 -0400

On Mon, 4 Apr 1994, David L Miller wrote:

> Date: Mon, 4 Apr 1994 17:25:20 -0700 (PDT)
> From: David L Miller <[email-masked]>
> To: "G. H. Chinoy" <[email-masked]>
> Cc: [email-masked]
> Subject: Re: different beep on new message?
> 
> 
> Hussain,
> 

If you feel like dealing with a little complexity, you can use procmail 
to do this (I assume it will run on a Next).  For example, the 
.procmailrc command:

#-----------------------------------------------------------------------------------
# Lets play a sound file for each incoming message and continue processing
# Will have to throw away the piped data and then execute the play program
# Will just send the header to pipe as smaller.  Wish could turn it off!
:0 hc
 |cat > /dev/null ; /usr/local/audio/play /usr/local/audio/MeepMeep.au

Does what you want for me.  Of course, procmail lets you do a lot more 
with incoming mail.  I have attached two readme files on procmail if you 
are interseted.

   -- Jim

> > arrives?  We're using NeXT machines running NeXTstep 3.0.

==========================================================================
James D. Dryfoos                   | [email-masked]
MIT Lincoln Labs, Group 28         |
244 Wood Street, MailStop: C159    | (617) 981-2008 - office
Lexington, MA 02173, Earth         | (617) 981-0782 - fax
==========================================================================

For installation instructions see the INSTALL file.
----------------------
Procmail & formail mail processing package.
Copyright (c) 1990-1993, S.R. van den Berg, The Netherlands.

Some legal stuff:

Use this software package at your own risk.  The programmer cannot
be held liable for any incurred damages, directly or indirectly due to
the use or inability to use this software.

You are encouraged to distribute this package freely.  This package is
however not to be sold (minor transfer costs excepted) or included in
any commercially sold software package (if you want to do this anyway,
contact me (address below), and we'll work something out).

If you distribute it, please leave the package intact.	You are allowed to
take parts from this distribution and distribute these separately as long
as you retain the copyright messages.  If you redistribute any part of this
package in a modified form, be sure to mark the parts you changed.
If you have some important changes that might be useful to the rest of the
world, contact me instead.

-------------------------- SYSTEM REQUIREMENTS -------------------------------

Any *NIX-alike system.

Sendmail, smail, MMDF, mailsurr or compatible mailers (in effect any mailer
that can process RFC-822 compliant mails).

The most important system calls that need to be supported (among others):
dup(),wait(),getpwnam(),fork(),pipe()

For a more complete list of all library references see "src/includes.h"

------------------------------ DESCRIPTION -----------------------------------

The procmail mail processing program. (v2.90 1993/07/01)

Can be used to create mail-servers, mailing lists, sort your incoming mail
into separate folders/files (real convenient when subscribing to one or more
mailing lists or for prioritising your mail), preprocess your mail, start
any programs upon mail arrival (e.g. to generate different chimes on your
workstation for different types of mail) or selectively forward certain
incoming mail automatically to someone.

The accompanying formail program enables you to generate autoreplies, split up
digests/mailboxes into the original messages, do some very simple
header-munging/extraction, or force mail into mail-format (with leading From
line).

Also included is a comprehensive mailinglist/archive management system.

----------------------

I made the utmost effort to make procmail as robust as any program can be
(every conceivable system error is caught *and* handled).

Procmail was designed to deliver the mail under the worst conditions
(file system full, out of swap space, process table full, file table full,
missing support files, unavailable executables; it all doesn't matter).
Should (in the unlikely event) procmail be unable to deliver your mail
somewhere, the mail will bounce back to the sender or reenter the mailqueue
(your choice).

For a more extensive list of features see the FEATURES file.

----------------------

However, as with any program, bugs cannot be completely ruled out.
I tested the program extensively, and believe it should be relatively
bug free (no known bug at the time).  Should, however, anyone find any
bugs (highly unlikely :-), I would be pleased (well, sort of :-) to hear
about it.  Please send me the patches or bug report.
I'll look at them and will try to fix it in a future release.
(BTW, if you should find any spelling or grammar errors in these files,
don't hesitate to point them out to me; I like correct English just as much
as you do).

----------------------

I would like to take the opportunity to express my gratitude in particular
to these devoted users of the procmail-package.	 Without their constant
feedback procmail would not have looked the same:

	David W. Tamkin		An excellent proofreader and betatester
	 <[email-masked]>
	Josh Laff		For stresstesting procmail (and me :-)
	 <[email-masked]>
	Dan Jacobson		For his many useful suggestions
	 <[email-masked]>
	Rick Troxel		Because I crashed his Convex way too often :-)
	 <[email-masked]>

----------------------

Please note that this program essentially is supposed to be static, that
means no extra features (honouring the VNIX spirit) are supposed to be
added (though any useful suggestions will be appreciated and evaluated if
time permits).

Cheers,
       Stephen R. van den Berg	at RWTH-Aachen, Germany.

Internet E-mail:		[email-masked]
				[email-masked]

Snail-Mail:	P.O.Box 21074
		6369 ZG Simpelveld
		The Netherlands

Procmail mailinglist:		[email-masked]

----------------------
A recent version can be picked up at various comp.sources.misc archives.
The latest version can be obtained directly from the ftp-archive at:

	ftp.informatik.rwth-aachen.de (137.226.112.172)

	as zipped tar file:		pub/unix/procmail.tar.zip	<152KB
	as compressed tar file:		pub/unix/procmail.tar.Z		<216KB
	in compressed shar format:	pub/unix/procmail.??.Z	      11 parts
----------------------
Feature summary for procmail:
	+ It's less filling (i.e. small)
	+ Very easy to install (rated PG6 :-)
	+ Simple to maintain and configure because
	  all you need is actually only ONE executable (procmail)
	  and ONE configuration file (.procmailrc)
	+ Is event driven (i.e. gets invoked automagically when mail arrives)
	+ Does not use *any* temporary files
	+ Uses standard egrep regular expressions
	+ It poses a very low impact on your system's resources
	+ Allows for very-easy-to-use yes-no decisions on where the mail
	  should go (can take the size of the mail into consideration)
	+ Filters, delivers and forwards mail *reliably*
	+ Provides a reliable hook (you might even say anchor :-) for any
	  programs or shell scripts you may wish to start upon mail arrival
	+ Performs heroically under even the worst conditions
	  (file system full, out of swap space, process table full,
	  file table full, missing support files, unavailable executables,
	  denied permissions) and tries to deliver the mail somehow anyway
	+ Absolutely undeliverable mail (after trying every trick in the book)
	  will bounce back to the sender (or not, your choice)
	+ Is one of the few mailers to perform reliable mailbox locking across
	  NFS as well (DON'T use NFS mounted mailboxes WITHOUT installing
	  procmail; you may lose valuable mail one day)
	+ Supports four mailfolder standards: single file folders (standard
	  and nonstandard VNIX format), directory folders that contain one file
	  per message, or the similar MH directory folders (numbered files)
	+ Variable assignment and substitution is an extremely complete subset
	  of the standard /bin/sh syntax
	+ Provides a mail log file, which logs all mail arrival, shows
	  in summary whence it came, what it was about, where it went (what
	  folder) and how long (in bytes) it was
	+ Uses this log file to display a wide range of diagnostic and error
	  messages (if something went wrong)
	+ Does not impose *any* limits on line lengths, mail length (as long
	  as memory permits), or the use of any character (any 8-bit character,
	  including '\0' is allowed) in the mail
	+ It has man pages (boy, does *it* have man pages)
	+ Procmail can be used as a local delivery agent with comsat/biff
	  support (*fully* downwards compatible with /bin/mail); in which case
	  it can heal your system mailbox, if something messes up the
	  permissions
	+ Allows you to painlessly shift the system mailboxes into the
	  user's home directories
	+ It runs on virtually all (old and future) operating systems which
	  names start with a 'U' or end in an 'X' :-) (i.e. extremely portable
	  code; POSIX, ANSI C and K&R conforming)
	+ Is clock skew immune (e.g. in the case of NFS mounted mailboxes)
	+ Works with (among others?) sendmail, smail, MMDF and mailsurr

Feature summary for formail:
	+ Can generate auto-reply headers
	+ Can convert mail into standard mailbox format (so that you can
	  process it with standard mail programs)
	+ Can split up mailboxes into the individual messages
	+ Can split up digests into the individual messages
	+ Can split up saved articles into the individual articles
	+ Can do simple header munging/extraction

Feature summary for lockfile:
	+ Provides NFS-secure lockfiles to shell script programmers
	+ Gives normal users the ability to lock their system mailbox,
	  regardless of the permissions on the mail-spool directory