Help for Pine - Compiling
Building Pine is not difficult. There are several advantages about
building Pine that you can not get if you only get a precoompiled version.
For example, you can fix a bug as soon as a patch is available. The price
that you must pay in order to receive the advantages of compiling your own
source code is usually minimal and we will try to explain how to build
pine from scratch.
Getting the Source
The source code of Pine can be obtained from their ftp server at
ftp://ftp.cac.washington.edu/pine/. There are a few mirror places, for
http://www.rge.com/pub/mail/pine/. A more extensive list of mirror sites can be found
Also note that you can get the binary precompiled for many versions of
Pine. They do not however include SSL support.
What is the Latest Version of Pine?
The easiest way to determine what's the latest version and what
improvements it contains is to visit
this web page. The
latest version is always at the top of the list.
What else do I Get by Compiling Pine?
A few other software is included when you build Pine from source code.
Here is a list:
- c-client.a, is the compiled version of the c-client libary.
This library is located in the "/imap/c-client/c-client.a". You should
know that library is used to compile the imap server (imapd) and Pine. We
will talk about this library later.
- imapd, is the IMAP server. It's source code is in
- mtest, this is a test mail client, you can learn how to use the
c-client library just by reading its source code.
- libpico.a is the Pico library. Used to compile Pico and Pine.
It is located in "./pico/libpico.a".
- Pico, this is an easy to use text editor, compiled using the
- Pilot, is a file browser, also compiled with the libpico.a library.
- Pine, the main star. It's compiled with both the libpico and
c-client library (in other words is huge!)
- rpdump, a program used to copy configuration files kept in an imap
server to a local file.
- rpload, a program used to copy your configuration files to an
imap server, so that you don't have to create a new pinerc file for every
computer where you install Pine. The same configuration can be read from the
IMAP server, no matter where you go.
How Do I build Pine
In order to build all of the above you must move into the directory
that contains the source code of Pine and write a command of the form.
The only trick is to know what "xxx" is. Here is a table showing what
you should write (Note that this list was obtained from the makefile of the
c-client library. I can't test all of these claims. The actual codes in the
build command for Pine is a much smaller set, but I decided to list all of
these in the hope that if you can try them and make something out of it. It
also explains the real set of codes that you can use to build Pine much better
than the build script for Pine).
|a32||AIX 3.2 for RS/6000|
|a41||AIX 4.1 for RS/6000|
|am2||AmigaDOS with a 68020+|
|ama||AmigaDOS using AS225R2|
|amn||AmigaDOS with a 680x0|| using "new" socket library|
|aos||AOS for RT|
|art||AIX 2.2.1 for RT|
|bs3||BSD/i386 3.0 and higher|
|bsd||generic BSD 4.3|
|d-g||DG/UX prior to 5.4|
|do4||Apollo Domain/OS sr10.4|
|dpx||Bull DPX/2 B.O.S.|
|gas||GCC Altos SVR4|
|gh9||GCC HP-UX 9.x|
|ghp||GCC HP-UX 10.x|
|ghs||GCC HP-UX 10.x with Trusted Computer Base|
|go5||GCC 2.7.1 (95q4 from Skunkware _not_ 98q2!) SCO Open Server 5.0.x|
|gsc||GCC Santa Cruz Operation|
|gul||GCC RISC Ultrix (DEC-5000)|
|hxd||HP-UX 10.x with DCE security|
|lnx||Linux||traditional passwords and crypt() in the C library|
|lnp||Linux|| with Pluggable Authentication Modules (PAM)|
|mnt||Atari ST Mint|
|nto||QNX Neutrine RTP|
|os4||OSF/1 4||Digital UNIX|
|osx||Mac OS X|
|s40||SUN-OS 4.0||not Solaris|
|sc5||SCO Open Server 5.0.x|
|sco||Santa Cruz Operation|
|shp||HP-UX with Trusted Computer Base|
|sgi||Silicon Graphics IRIX|
|sg6||Silicon Graphics IRIX 6.5|
|sl4||Linux||using -lshadow to get the crypt() function|
|sl5||Linux||with shadow passwords, no extra libraries|
|slx||Linux||using -lcrypt to get the crypt() function|
|snx||Siemens Nixdorf SININX or Reliant UNIX|
|sol||Solaris||won't work unless "ucbcc" works -- use gso instead|
|sos||OSF/1 with SecureWare|
|ssn||SUN-OS||with shadow password security|
|sun||SUN-OS 4.1 or better||not Solaris|
|sv2||SVR2 on AT&T PC-7300||incomplete port|
|ult||RISC Ultrix (DEC-5000)|
|vu2||VAX Ultrix 2.3||e.g. for VAXstation-2000 or similar old version|
Will Pine Build on my System?
If your system is not in the above list, it may be possible to have
Pine available in your system, but probably there must be a portability
issue, and you will probably have to get it through a third party vendor.
What are the most common parameters that people need to consider before compiling Pine?
There are several, I'm not going to talk about the 60MB of disk space that
you need in order to build Pine, this section deals with parameters that
affect the end result of this compilation.
- Debug Files: The people that consider this option, usually
disable this feature. If you want to disable debug, all you need to do is
to edit the corresponding makefile for your system and delete from the definition of the variable. The rest of the information here will
tell you what happens when you do not disable debugging.
If you do not do what was mentioned in the above paragraph, Pine will be
compiled with DEBUG support. What this means in practice is that not
disabling this feature, will make that every time that you start Pine,
Pine will create a file called ".pine-debug1", which will contain trace
information of the program. If there is already a file called
.pine-debug1, then pine will rename that file to be called .pine-debug2,
and so on. The default is that there are only, at most 4 debug files. You
can change the number of debug files that are kept by default by editing
the file pine/os.h and changing the definition of
#define NUMDEBUGFILES 4
Debug files are never bigger than 200K in size; Pine stops
writing to the debug files, once they reach this size.
Pine documents only 9 debug levels, and 4 debug levels for imap, but in
reality there are 11 debug levels for Pine and 5 debug levels for imap. The
following table is taken from the source code of Pine. To start Pine at level
4, use the following command
pine -d 4
The default is that Pine will set the debug level at 2, and no imap debug
information will be recorded. Remember that setting the debug level to any
number has the effect of recording all debug information of lower level
too, it does not only record the debug level that you set. Here are their
The default debug level to set (approximate meanings):
0 disables debug for the current session
1 logs only highest level events and errors
2 logs events like file writes
4 logs each command
7 logs details of command execution (7 is highest to run any production)
9 logs gross details of command execution
Debug levels bigger than 9 produce a message starting Pine, which warns you
that sensitive information is being recorded in the .pine-debug1 file.
Level 10 records the entries in your password files and shows you which
entry is being tested. The imap log is also complete, and with that
information anyone can read your e-mail. You should never use this level,
unless of course you forgot your password and you need it for something.
Some information about your addressbook is also recorded, which does not have
any importance for normal users.
Level 11 records more detailed information of the processing of mailcap
files, and records some information related to the address book, which is not
relevant for users (only for programmers).
Notice that if you are running Pine with a positive debug level, you can
change the debug level by going to the main screen and entering the
corresponfing debug level, so if you are running Pine in default debug
level, then you can change it to debug level 9 by going to the main screen
and pressing the number 9 key. You can not disable debugging in this form.
Now let's talk about the debug levels for imap, Here are their meanings:
0 no recording is done, this is the default
2 only attempts of connections and their outcomes are recorded
3 records the results of checking for mail in external folders.
4 records almost all session, including what was broadcasted through
the wire between Pine and the server (set by debug level 9)
5 Full imap information, includes the passwords that were attempted
to connect to the server (set by debug level 10)
You can start Pine at level 3, say by starting Pine with the command:
pine -d imap=3
You can also combine these two debug levels, and start Pine with a command like
pine -d 3 -d imap=5
New in version 4.50 is the ability to see your debug file at any level
without quitting Pine. This can not be done in all platforms, it may require
recompilation of Pine. In general this is done by adding the
option to the corresponding
makefile for Pine under the definition.
- Unix Proto: This corresponds to the default format that Pine
will use to create new folders. In the default configuration of Pine, this
format is set to be the Berkeley format, called here, the Unix format. It
is the most common format in use today in Unix systems. It distiguishes
from other formats in that the first line of each message begins with the
"From " string. Here you can find more
information about this format.
Sometimes groups of people decide to share folders, and the Unix format,
which does no allow this, is insufficient. In this case, people use
another format called mbx, and one can force Pine to create folders in
this format by default.
If you ever need to do this, all you need to do is to edit the file
imap/src/osdep/unix/Makefile and change the value of CREATEPROTO to be
- Mbox Driver: This is a controversial driver,
and in my personal opinion if you had a choice as an administrator,
disable it, before it's too late.
The mbox driver is another name for your INBOX. The difference is that mail
will be put in the $HOME directory of your account, not in the spool, not kept
in the server, but transfered to your (unix) account.
If you are a system administrator, that sounds great, because users will not
be filling up the spool, which is a shared space. Here are the bad news. Regardless
of which IMAP/POP3 server that you use, your users may complain to you that they
have lost their mail!. The bigger the environment (or the smaller it is), if you
need to support e-mail, this may turn out to be a nightmare, so it's best not
to deal with it.
First, let's see what are the conditions to activate this driver. In the
first place you need to support some kind of Unix system (or Linux), and
users must have a file called in their $HOME
directory. That file may be there, because before your users decided to
use Pine, they may have used other programs (like Unix mail) that used the
mbox file to store saved messages, for example.
If the above file is in Unix format,
then Pine (or the server) may use it to transfer messages saved in the
spool (or the server) to the mbox file, where messages will be appended to
the existing messages there. This process succeeds if you create an empty
file called mbox in your $HOME directory. Whenever this is done, Pine
adjusts its INBOX path to point out to the mbox file, so Pine users won't
see lost mail.
This sounds great, because it's a nice scheme for reading e-mail. The
drawback is the following. Say you allow your users local and remote
access to their INBOX, for example, local access when they are logged in
in the office and remote from home. Now say that they have the mbox file
in their directory, and they use Pine to read e-mail in the office.
Silently, without the user noticing, that e-mail is sitting in the mbox
file. Now say the user wants to connect from home, and the server installed
in your system is not any of the UW-IMAP/POP3 servers, then when the user
open his/her INBOX s/he will see no mail, because the server is looking for
e-mail in the spool directory, and not in the $HOME directory of the user.
This is specially bad if your user is your boss who left home to reply to
a message later from home, and not only they find that they can not do it, but
also that their e-mail is lost!
If you choose to disable the mbox driver, you can do it when
compiling Pine (or the UW-IMAP/POP3 servers). Edit the file
imap/src/osdep/unix/Makefile and delete the value of EXTRADRIVERS, so that it
Some other (partial) solutions are possible too, if you forgot to disable this driver at
compilation time. You can edit your system wide Pine configuration file
(pine.conf), and add the following line:
If you decide not to do this, users can add the above line in their own
.pinerc files to disable this driver.
Be careful, the above means that the mbox driver will be disabled for
local reading only, if a user disables the mbox driver for reading e-mail
in the above mentioned way, and you use the UW-IMAP/POP3 server, then
again users may find that they lost e-mail. This is because, as in the
above example, if your user reads e-mail from home through a remote
connection, that person will see all his/her e-mail in the mbox file, so
when that person comes back to office all his/her mail will be gone, because
the mbox driver is disabled.
It's a no win situation.
You can however fix this by either always making users connect remotely to
the server (and always or never using the UW-IMAP/POP3 servers), or always
only allowing local access (even if this means through a telnet
connection). Even then, those users who do not want to have their mail
sitting in their $HOME directory will go to big pain to synchronize their
INBOX (in the spool and in their $HOME directory), if they ever have an
mbox file in their $HOME directory, since as we saw before we can disable
it for local access, but regardless of what you do, you can not disable
this driver for remote access. In other words, there's no much one can do
to fight against this behavior, once it is compiled in.
There is a patch, however, which can be used to disable this driver if
your user connects remotely from a unix system.
My advice is disable this driver before it's too late.
- mbx INBOX: In the same way that the
~/mbox file is your INBOX, the file ~/INBOX, if it exists and it is in mbx
format, will serve as your local INBOX. This is normally not a problem,
since by definition of the mbx format, no empty file can be in mbx format.
A password file allows users to save their passwords in a file, so that
they do not have to enter them every time that they connect to their
You can only enable password file support when you build Pine. This is
not binding, in the sense that even if you enable it you must still create
the password file in order to be able to use it.
The only sure way to define a password file is to edit the file
pine/pine.h and add the following line to it:
#define PASSFILE "path/to/password/file"
and after this, build Pine (again if necessary). I usually enter the
above definition normally almost at the top of the file, around the area
where the Pine version is defined. This is a change in the source code
of Pine, not in the configuration of Pine.
If you are using a version of Pine older than Pine4.41, then the path
specified above is relative to the directory where the pinerc file of the
user using Pine is located (this is normally the $HOME directory, but it
may be a different place). You can also specify a full path if you like.
At this time the password file feature was thought to be used only by
the person compiling pine, not for use in a system, that means that if you
want to use this system, you will have to compile your own version of
Starting in version 4.43, PC-Pine allows you to define any path for the
password file, and all you need to do is to start PC-Pine as
Once you have a working version of Pine with password file support, if
you are using version 4.55 or later you can change the location of the
default location (defined by the PASSFILE variable), by using the
-passfile command line.
If you want to use the passfile option as a user, you need to create
an empty file with the name as specified in the PASSFILE variable as discussed
above. When Pine is started, Pine removes all permissions for group and world
to access your password file, so that your password file can not be
read by other users in your system.
When Pine finds a match on the server and username it uses the
password found in the password file. If no good password is found, or none
exists in the password file, you will be prompted to enter your password, and
later be offered to save the password in the password file. You can avoid that
Pine saves your password in the password file if you use the option
when you start Pine.
About Fixing Bugs
Bugs are Nature's Bugs
Fixing a bug requires recompiling Pine, that's no news. Sometimes, for
unknown reasons to me, bugs are fixed but not publicized, and this is
especially true when the bug is in the imap part of the code of Pine (that
is to say the c-client library).
Given that many times patches are not distributed to fix bugs, all I
can recommend is that you try to upgrade the imap part of the code in
Pine. In order to do this, try removing the imap/ directory from the
distribution of pine and replacing this directory by a new imap directory
(with the same name as before) from the distribution of the server code
About Header Files
Pine is distributed with the c-client and pico libraries. Each of these
libraries has specific header files, which are included by default in the
If you are creating a new module for Pine, make sure you include
headers.h. You do not need to include any other headers file, unless it's
specific to your module. For example, the files
included by including the file .
Notice that as of the current version of Pine (4.44), the file os.h is
included before pine.h. What this means in practice is that if you are
inserting a #define statement, it's usually easier to insert it in the
file pine.h, and that overriding definitions in the file os.h can be done
by inserting them in the file pine.h by undefining the definition of the
file os.h. In case a black hand changed the order of the inclusion of the
files os.h and pine.h, this trick won't work anymore, and it's recommended
to use this trick in the file headers.h, after all files have been
How Do I Build Pine in...
You can build a non ssl version of pine with the command "build slx", but
if you need to access a secure server this command will not be enough for you,
so if you want to build a secure version you need to decide if you want to
use Kerberos or not. The above is because RedHat messed up and made SSL include
- (recommended, specially if
you don't know what this is). Use the command
./build EXTRACFLAGS='-DOPENSSL_NO_KRB5' lrh
- Use the command:
./build EXTRACFLAGS='-I/usr/kerberos/include' \
In order to build secure version of Pine (one thtat supports SSL), try to
use the following command:
./build SSLCERTS=/etc/ssl/certs SSLINCLUDE=/usr/include/openssl \
It was reported by Nancy McGough that the following command could be used
to build Pine on FreeBSD-5.3-RELEASE #0
SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib bsf
These directions are based on directions that can be found
You may want to install libpam0g-dev. The Debian package lists as build
dependencies: libncurses5-dev, libldap2-dev, libssl-dev.