# Behind the Scenes

Many people ask how certain Alpine features are implemented. This section outlines some of the details.

## Address Books

There are two types of address book storage. There are local address books, which are the address books that are stored in a local file; and there are remote address books, which are stored on an IMAP server.

#### Information About Remote Address Books

> NOTE: The remote address book capability does not allow you to access an existing local address book from a remote system! That is, you can't set the remote address book to something like `{remote.host}.addressbook` and expect to access the existing `.addressbook` file on remote.host. Instead, you need to create a new remote address book in a new, previously unused remote mail folder. Then you can use the Select and Apply Save commands in the address book screen to Save all of the entries from an existing local address book to the new remote address book.

A remote address book is stored in a mail folder on an IMAP server. An Alpine remote address book is just like an Alpine local address book in that it is not interoperable with other email clients. The folder is a regular folder containing mail messages but those messages are special. The first message must be an alpine remote address book header message which contains the header x-pine-addrbook. The last message in the folder contains the address book data. In between the first and the last message are old versions of the address book data. The address book data is simply stored in the message as it would be on disk, with no MIME encoding. When it is used the data from the last message in the folder is copied to a local file and then that file is used exactly like a local address book file is used. When a change is made the modified local file is appended to the remote folder in a new message. In other words, the local file is just a cache copy of the data in the remote folder. Each client which uses the remote address book will have its own cache copy of the data. Whenever a copy is done the entire address book is copied, not just the entries which have changed.

Alpine can tell that the remote data has changed by one of several methods. If the date contained in the Date header of the last message has changed then it knows it has changed. If the UID of the last message has changed, or the number of messages in the folder has changed, it knows that it has changed. When Alpine discovers the folder has changed it gets a new copy and puts it in the local cache file.

There is a configuration file variable for remote address books called remote-abook-metafile. The variable is the name of a file in which information about remote address books is stored. There is one line in the metafile for each remote address book. The information stored there is the name of the cache file and information to help figure out when the remote folder was last changed. If the metafile or any of the cache files is deleted then Alpine will rebuild them the next time it runs.

Remote address books have names that look just like regular remote mail folder names. For example:

> {host.domain}foldername

Alpine decides whether or not an address book is remote simply by looking at the first character of the address book name and comparing it to '{'.

#### Information About All Address Books

The address book is named, by default, `.addressbook` in the user's Unix home directory, or in the case of PC-Alpine, `ADDRBOOK`, in the same directory as the `PINERC` file. There may be more than one address book, and the default name can be overridden via an entry in any of the Alpine configuration files. The two configuration variables address-book and global-address-book are used to specify the names of the address books. Each of these variables is a list variable. The total set of address books for a user is the combination of all the address books specified in these two lists. Each entry in the list is an optional nickname followed by an address book name. The nickname is everything up to the last space before the file name. The global-address-book list will typically be configured in the system-wide configuration file, though a user may override it like most other variables. Address books which are listed in the global-address-book variable are forced read-only, and are typically shared among multiple users.

Local address books (or local cache files for remote address books) are simple text files with lines in the format:

> <nickname>TAB<fullname>TAB<address>TAB<fcc>TAB<comments>

The last two fields are optional. A "line" may be made up of multiple actual lines in the file by using continuation lines, which are lines beginning with SPACE characters. The line breaks may be after TABs or in between addresses in a distribution list. Each actual line in the file must be less than 1000 characters in length.

Nicknames (the first field) are short names that the user types instead of typing in the full address. There are several characters which aren't allowed in nicknames in order to avoid ambiguity when parsing the address (SPACE, COMMA, @, ", ;, :, (, ), [, ], <, >, \). Nicknames aren't required. In fact, none of the fields is required.

The fullname field is usually stored as Last_name, First_name, in order that a sort on the fullname field comes out sorted by Last_name. If there is an unquoted comma in the fullname, Alpine will flip the first and last name around and get rid of the comma when using the entry in a composition. It isn't required that there be a comma, that's only useful if the user wants the entries to sort on last names.

The address field takes one of two forms, depending on whether the entry is a single (simple) address or a distribution list. For a simple entry, the address field is an RFC 2822 address. This could be either the email-address part of the address, i.e., the part that goes inside the brackets (<>), or it could be a full RFC 2822 address. The phrase part of the address (the fullname) is used unless there is a fullname present in the fullname field of the address book entry. In that case, the fullname of the address book entry replaces the fullname of the address. For a distribution list, the <address> is in the format:

> "(" <address>, <address>, <address>, ... ")"

The only purpose for the parentheses around the list of addresses is to make it easier for the parsing routines to tell that it is a simple entry instead of a list. The two are displayed differently and treated slightly differently in some cases, though most of the distinction has disappeared. Each of the addresses in a list can be a full RFC 2822 address with fullname included, or it may be just the simple email-address part of the address. This allows the user to have a list which includes the fullnames of all the list members. In both the simple and list cases, addresses may also be other nicknames which appear in this address book or in one of the other address books. (Those nicknames are searched for by looking through the address books in the order they appear in the address book screen, with the first match winning.) Lists may be nested. If addresses refer to each other in a loop (for example, list A includes list B which includes list A again) this is detected and flagged. In that case, the address will be changed to "**** address loop ****".

The optional fcc field is a folder name, just like the fcc field in the composer headers. If the first address in the To field of a composition comes from an address book entry with an fcc field, then that fcc is placed in the fcc header in the composer.

The comments field is just a free text field for storing comments about an entry. By default, neither the fcc nor the comments field is shown on the screen in the address book screen. You may make those fields visible by configuring the variable addressbook-formats. They are also searched when you use the WhereIs command in the address book screen and are visible when you View or Update an entry.

The address book is displayed in the order that it is stored. When the user chooses a different sorting criterion, the data is actually sorted and stored, as opposed to showing a sorted view of the data.

When the address book is written out, it is first written to a temporary file and if that write is successful it is renamed. This guards against errors writing the file that might destroy the whole address book. The address book is re-written after each change. If the address book is a remote address book, the file is then appended to the remote mail folder using IMAP.

The end-of-line character(s) in the address book file are those native to the system writing it. So it is <LF> on Unix and <CR><LF> on PC's. However, both Unix and PC versions of Alpine can read either format, so it should be possible to share a read-only address book among the two populations (using NFS, for example).

### Address Book Lookup File

Pine used an additional file for each address book, called the LookUp file. It had the same name as the address book file with the suffix ".lu" appended. Alpine no longer uses a lookup file.

#### Validity Checking of Address Books

There is no file locking done on Alpine address books, however, there is considerable validity checking done to make sure that the address book hasn't changed unexpectedly. Whenever the address book is about to be changed, a check is made to see if the file is newer than when we read it or the remote address book folder has changed since we last copied it. If either of these is true, the change is aborted.

There is an automatic, behind-the-scene check that happens every so often, also. For example, if someone else changes one of the address books that you have configured, your Alpine's copy of the address book will usually be updated automatically without you noticing. This checking happens at the same time as new mail checking takes place, unless you are actively using the address book, in which case it happens more frequently.

## Remote Configuration

Configuration information may be stored remotely. Remote configuration information is stored in a folder on an IMAP server. This should be a folder which is used only for storing the configuration information. In other words, it should be a folder which didn't exist before.

Remote configuration folders are very similar to remote address book folders. They both consist of a header message, which serves to identify the type of folder; the last message, which contains the data; and intermediate messages, which contain old versions of the data. The first message must contain the header x-pine-pinerc.

When a remote configuration is being used, the folder is checked to make sure it is a remote configuration folder, then the data contained in the last message is copied to a temporary file. That file is treated just like any regular local configuration file from that point on. Whenever a configuration change is made, the entire file is copied back to the IMAP server and is appended to the folder as a new message.

Because remote configuration folders are so similar to remote address books, the configuration variable remote-abook-metafile is used by both.

Remote configuration folders have names that look just like regular remote mail folder names. For example:

> {host.domain}mypinerc

Alpine decides whether or not a configuration file is remote simply by looking at the first character of the name and comparing it to '{'.

## Checkpointing

Periodically Alpine will save the whole mail folder to disk to prevent loss of any mail or mail status in the case that it gets interrupted, disconnected, or crashes. The period of time Alpine waits to do the checkpoint is calculated to be minimally intrusive. The timing can be changed (but usually isn't) at compile time. Folder checkpointing happens for both local folders and those being accessed with IMAP. The delays are divided into three categories:

> The exact algorithm given below is no longer correct. It has gotten more complicated over time. However, this gives the general idea Alpine uses when deciding whether or not to do a checkpoint.

Good Time:
  This occurs when Alpine has been idle for more than 30 seconds. In this case Alpine will checkpoint if 12 changes to the file have been made or at least one change has been made and a checkpoint hasn't been done for five minutes.

Bad Time:
  This occurs just after Alpine has executed some command. Alpine will checkpoint if there are 36 outstanding changes to the mail file or at least one change and no checkpoint for ten minutes.

Very Bad Time:
  Done when composing a message. In this case, Alpine will only checkpoint if at least 48 changes have been made or at least one change has been made in the last twenty minutes with no checkpoint.

## Debug Files

If UNIX Alpine is compiled with the compiler DEBUG option on (the default), then Alpine will produce debugging output to a file. This can be disabled at compile-time with the --disable-debug configure option, or at run-time with the command line flag -d0. The file is normally `.pine-debugX` in the user's home directory where X goes from 1 to 4. Number 1 is always the most recent session and 4 the oldest. Four are saved because often the user has gone in and out of Alpine a few times after a problem has occurred before the expert actually gets to look at it. The amount of output in the debug files varies with the debug level set when Alpine is compiled and/or as a command line flag. The default is level 2. This shows very general things and records errors. Level 9 produces copious amounts of output for each keystroke.

Similarly, PC-Alpine creates debug files named `pinedebg.txtX` in the same directory as the `PINERC` file.

## INBOX and Special Folders

The INBOX folder is treated specially. It is normally kept open constantly so that the arrival of new mail can be detected. The name INBOX refers to wherever new mail is retrieved on the system. If the inbox-path variable is set, then INBOX refers to that. IMAP servers understand the concept of INBOX, so specifying the folder {imap.u.example.edu}INBOX is meaningful. The case of the word INBOX is not important, but Alpine tends to display it in all capital letters.

The folders for sent mail and saved messages folders are also somewhat special. They are automatically created if they are absent and recreated if they are deleted.

## Internal Help Files

The file `pine.hlp` in the `alpine` subdirectory of the distribution contains all the help text for Alpine. It is compiled right into the Alpine binary as strings. This is done to simplify installation and configuration. The `pine.hlp` file is in a special format that is documented at the beginning of the file. It is divided into sections, each with a name that winds up being referenced as a global variable. This file is processed during the build process and turned into a C file that is compiled into Alpine.

## International Character Sets

Alpine uses Unicode characters internally and it is a goal for Alpine to handle email in many different languages. Alpine will properly display only left-to-right character sets in a fixed-width font. Specifically, Alpine assumes that a fixed-width font is in use, in the sense that characters are assumed to take up zero, one, or two character cell widths from left to right on the screen. This is true even in PC-Alpine.

Alpine recognizes some local character sets which are right-to-left (Arabic, Hebrew, and Thai) or not representable in a fixed-width font (Arabic) and properly converts texts in these character sets to/from Unicode; however, there are known display bugs with these character sets.

There are three possible configuration character settings and some environment variable settings which can affect how Alpine handles international characters. The first two of these are only available in UNIX Alpine. The three configuration options are display-character-set, keyboard-character-set, and posting-character-set. The keyboard-character-set defaults to being the same value as the display-character-set, and that is usually correct, because the keyboard almost always produces characters in the same character set as the display displays. The display-character-set is the character set that Alpine will attempt to use when sending characters to the display.

Besides those variables there is also use-system-translation which can be used instead of these. That usage is only lightly tested and is not recommended.

By default, the display-character-set variable is not set and UNIX Alpine will attempt to get this information from the environment. In particular, the `nl_langinfo(CODESET)` call is used. This usually depends on the setting of the environment variables LANG or LC_CTYPE. An explicit configuration setting for display-character-set will, of course, override any default setting.

For PC-Alpine the display-character-set and the keyboard-character-set are always equivalent to `UTF-8` and this is not settable.

It is probably best to use UNIX Alpine in a terminal emulator capable of displaying UTF-8 characters, since that will allow you to view just about any received text that is correctly formatted (note, however, the above comments about known index display bugs with certain character sets). You'll need to have an emulator which uses a UTF-8 font and you'll need to set up your environment to use a UTF-8 charmap. For example, on a Linux system you might include

`setenv LANG en_US.UTF-8`

or something similar in your UNIX startup files. You'd also have to select a UTF-8 font in your terminal emulator.

The types of values that the character set variables may be set to are `UTF-8`, `ISO-8859-1`, or `EUC-JP`. The `ISO-2022` character sets are not supported for input or for display, but as a special case, `ISO-2022-JP` is supported for use only as a posting-character-set. In the Setup/Config screen you may choose from a list of all the character sets Alpine knows about by using the "T" ToCharsets command. Here is a list of many of the possible character sets:

UTF-8 | Unicode
US-ASCII | 7 bit American English characters
ISO-8859-1 | 8 bit European "Latin 1" character set
ISO-8859-2 | 8 bit European "Latin 2" character set
ISO-8859-3 | 8 bit European "Latin 3" character set
ISO-8859-4 | 8 bit European "Latin 4" character set
ISO-8859-5 | 8 bit Latin and Cyrillic
ISO-8859-6 | 8 bit Latin and Arabic
ISO-8859-7 | 8 bit Latin and Greek
ISO-8859-8 | 8 bit Latin and Hebrew
ISO-8859-9 | 8 bit European "Latin 5" character set
ISO-8859-10 | 8 bit European "Latin 6" character set
ISO-8859-11 | Latin and Thai
ISO-8859-12 | Reserved
ISO-8859-13 | 8 bit European "Latin 7" character set
ISO-8859-14 | 8 bit European "Latin 8" character set
ISO-8859-15 | 8 bit European "Latin 9" character set
ISO-8859-16 | 8 bit European "Latin 10" character set
KOI8-R | 8 bit Latin and Russian
KOI8-U | 8 bit Latin and Ukranian
WINDOWS-1251 | 8 bit Latin and Russian
TIS-620 | 8 bit Latin and Thai
VISCII | 8 bit Latin and Vietnamese
GBK | Latin and Chinese Simplified
GB2312 | Latin and Chinese Simplified
CN-GB | Latin and Chinese Simplified
BIG5 | Latin and Chinese Traditional
BIG-5 | Latin and Chinese Traditional
EUC-JP | Latin and Japanese
SHIFT-JIS | Latin and Japanese
EUC-KR | Latin and Korean
KSC5601 | Latin and Korean

When reading incoming email, Alpine understands many different character sets and is able to convert the incoming mail into Unicode. The Unicode will be converted to the display-character-set for display on your terminal. Characters typed at the keyboard will be converted from the keyboard-character-set to Unicode for Alpine's internal use. You may find that you can read some malformed messages that do not contain a character set label by setting the option unknown-character-set.

The posting-character-set is used when sending messages. The default behavior obtained by leaving this variable unset is usually what is wanted. In that default case, Alpine will attempt to label the message with the most specific character set from the rather arbitrary set

US-ASCII, ISO-8859-15, ISO-8859-1, ISO-8859-2, VISCII, KOI8-R, KOI8-U, ISO-8859-7, ISO-8859-6, ISO-8859-8, TIS-620, ISO-2022-JP, GB2312, BIG5, EUC-KR, and UTF-8.

For example, if the message is made up of only US-ASCII characters, it will be labeled US-ASCII. Otherwise, if it is all ISO-8859-15 characters, that will be the label. If that doesn't work the same is tried for the remaining members of the list.

It might make sense to set posting-character-set to an explicit value instead. For example, if you usually send messages in Greek, setting this option to ISO-8859-7 will result in messages being labeled as US-ASCII if there are no non-ascii characters, ISO-8859-7 if there are only Greek characters, or UTF-8 if there are some characters which aren't representable in ISO-8859-7. Another possibility is to set this option explicitly to UTF-8. In that case Alpine labels only ascii messages as US-ASCII and all other messages as UTF-8.

## Interrupted and Postponed Messages

If the user is composing mail and is interrupted by being disconnected (SIGHUP, SIGTERM or end of file on the standard input), Alpine will save the interrupted composition and allow the user to continue it when he or she resumes Alpine. As the next Alpine session starts, a message will be given that an interrupted message can be continued. To continue the interrupted message, simply go into the composer. To get rid of the interrupted message, go into the composer and then cancel the message with ^C.

Composition of half-done messages may be postponed to a later time by giving the ^O command. Other messages can be composed while postponed messages wait. All of the postponed messages are kept in a single folder. Postponing is a good way to quickly reference other messages while composing.

## Message Status

The c-client library allows for several flags or status marks to be set for each message. Alpine uses four of these flags: UNSEEN, DELETED, ANSWERED, and FLAGGED. The `N` in Alpine's FOLDER INDEX means that a message is unseen-it has not been read from this folder yet. The `D` means that a message is marked for deletion. Messages marked with `D` are removed when the user Expunges the folder (which usually happens when the folder is closed or the user quits Alpine). The `A` in Alpine's FOLDER INDEX means that the message has been replied-to. The `*` in Alpine's FOLDER INDEX means that the message has been ``flagged'' as important. That is, the user used the Flag command to turn the FLAGGED flag on. This flag can mean whatever the user wants it to mean. It is just a way to mark some messages as being different from others. It will usually probably be used to mark a message as somehow being ``important''. For Berkeley format folders, the message status is written into the email folder itself on the header lines marked `Status:` and `X-Status`.

It is also possible for a user to define their own flags in addition to the standard system flags above. In Alpine these user defined flags are called Keywords.

## MIME: Reading a Message

Alpine should be able to handle just about any MIME message. When a MIME message is received, Alpine will display a list of all the parts, their types and sizes. It will display the attachments when possible and appropriate and allow users to Save all other attachments.

Alpine honors the "mailcap" configuration system for specifying external programs for handling attachments. The mailcap file maps MIME attachment types to the external programs loaded on your system which can display and/or print the file. A sample mailcap file comes bundled with the Alpine distribution. It includes comments which explain the syntax you need to use for mailcap. With the mailcap file, any program (mail readers, newsreaders, WWW clients) can use the same configuration for handling MIME-encoded data.

If a `MAILCAPS` environment variable is defined, Alpine will use that to look for one or more mailcap files, which are combined. In the absence of `MAILCAPS`, Unix Alpine will look for a personal mailcap file in `~/.mailcap` and combine that with a system-wide file in `/etc/mailcap`. PC-Alpine will look for a file named `MAILCAP` in the same directory as the `PINERC` file, and/or the directory containing the `ALPINE.EXE` executable.

Messages which include rich text or enriched text in the main body will be displayed in a very limited way (it will show bold and underlining).

If Alpine sees a MIME message part tagged as type IMAGE, and Alpine's image-viewer configuration variable is set, Alpine will attempt to send that attachment to the named image viewing program. In the case of UNIX Alpine, the `DISPLAY` environment variable is checked to see if an X-terminal is being used (which can handle the images). If the image-viewer variable is not set, Alpine uses the mailcap system to determine what to do with IMAGE types, just as it does for any other non-TEXT type, e.g. type APPLICATION. For MIME's generic "catch all" type, APPLICATION/OCTET-STREAM, the mailcap file will probably not specify any action, but Alpine users may always Save any MIME attachment to a file.

MIME type "text/plain" is handled a little bit differently than the other types. If you are viewing the main body part in the MESSAGE TEXT viewing screen, then Alpine will use its internal viewer to display it. This happens even if there is a mailcap description which matches this particular type. However, if you view a part of type "text/plain" from the ATTACHMENT INDEX screen, then Alpine will check the mailcap database for a matching entry and use it in preference to its internal viewer.

Some text attachments, specifically those which are just other email messages forwarded as MIME messages, are displayed as part of the main body of the message. This distinction allows easy display when possible (the forward as MIME case) and use of an attachment viewer when that is desirable (the plain text file attachment case).

If the parts of a multipart message are alternate versions of the same thing Alpine will select and display the one best suited. For parts of type "message/external-body", the parameters showing the retrieval method will be displayed, and the retrieval process is automated. Messages of type "message/partial" are not supported.

## MIME: Sending a Message

There are two important factors when trying to include an attachment in a message: encoding and labeling. Alpine has rules for both of these which try to assure that the message goes out in a form that is robust and can be handled by other MIME mail readers.

MIME has two ways of encoding data-Quoted-Printable and Base64. Quoted-Printable leaves the ASCII text alone and only changes 8-bit characters to "=" followed by the hex digits. For example, "=09" is a tab. It has the advantage that it is mostly readable and that it allows for end of line conversions between unlike systems. Base64 encoding is similar to uuencode or btoa and just encodes a raw bit stream. This encoding is designed to get text and binary files through even the most improperly implemented and configured gateways intact, even those that distort uuencoded data.

All attachments are encoded using Base64 encoding. This is so that the attachment will arrive at the other end looking exactly like it did when it was sent. Since Base64 is completely unreadable except by MIME-capable mailers or programs, there is an obvious tradeoff being made here. We chose to ensure absolutely reliable transport of attachments at the cost of requiring a MIME-capable mailer to read them. If the user doesn't want absolute integrity he or she may always include text (with the ^R command) in the body of a message instead of attaching it. With this policy, the only time quoted-printable encoding is used is when the main body of a message includes special foreign language characters.

When an attachment is to be sent, Alpine sniffs through it to try to set the right label (content-type and subtype). An attachment with any lines longer than 500 characters in it or more than 10% of the characters are 8-bit it will be considered binary data. Alpine will recognize (and correctly label) a few special types including GIF, JPEG, PostScript, and some audio formats. Another method which can be more robust and flexible for determining the content-type and subtype is to base it on the file extension. This method uses a MIME.Types File.

If it is not binary data (has only a small proportion of 8-bit characters in it,) the attachment is considered 8-bit text. 8-bit text attachments are labeled "text/plain" with charset set to the value of the user's keyboard-character-set variable. If an attachment is ASCII (no 8-bit characters) and contains no control characters then it is considered plain ASCII text. Such attachments are given the MIME label "text/plain; charset=US-ASCII", regardless of the setting of the user's keyboard-character-set variable.

All other attachments are unrecognized and therefore given the generic MIME label "application/octet-stream".

## New Mail Notification

Alpine checks for new mail in the INBOX and in the currently open folder every two and a half minutes by default. This default can be changed in the system-wide configuration file or at compile-time with the --with-mailcheck-interval=VALUE configuration option. A user can change it by changing the option mail-check-interval. A new mail check can be manually forced by redrawing the screen with a ^L.

When there is new mail, the message(s) will appear in the index, the screen will beep, and a notice showing the sender and subject will be displayed. If there has been more than one new message since you last issued a command to Alpine, the notice will show the count of new messages and the sender of the most recent one.

## NFS

It is possible to access mail folders on NFS mounted volumes with Alpine, but there are some drawbacks to doing this, especially in the case of incoming-message folders that may be concurrently updated by Alpine and the system's mail delivery agent. One concern is that Alpine's user-contention locks don't work because /tmp is usually not shared, and even if it was, flock() doesn't work across NFS.

The implementation of the standard UNIX ".lock" file locking has been modified to work with NFS as follows. Standard hitching post locking is used so first a uniquely named file is created, usually something like xxxx.host.time.pid. Then a link to it is created named xxxx.lock where the folder being locked is xxxx. This file constitutes the lock. This is a standard UNIX locking scheme. After the link returns, a stat(2) is done on the file. If the file has two links, it is concluded that the lock succeeded and it is safe to proceed.

In order to minimize the risks of locking failures via NFS, we strongly recommend using IMAP rather than NFS to access remote incoming message folders, e.g. your INBOX. However, it is generally safe to access personal saved-message folders via NFS since it is unlikely that more than one process will be updating those folders at any given time. Still, some problems may occur when two Alpine sessions try to access the same mail folder from different hosts without using IMAP. Imagine the scenario: Alpine-A performs a write that changes the folder. Alpine-B then attempts to perform a write on the same folder. Alpine-B will get upset that the file has been changed from underneath it and abort operations on the folder. Alpine-B will continue to display mail from the folder that it has in its internal cache, but it will not read or write any further data. The only thing that will be lost out of the Alpine-B session when this happens is the last few status changes.

If other mail readers besides Alpine are involved, all bets are off. Typically, mailers don't take any precautions against a user opening a mailbox more than once and no special precautions are taken to prevent NFS problems.

## Printers and Printing

UNIX Alpine can print to the standard UNIX line printers or to generic printers attached to ANSI terminals using the escape sequences to turn the printer on and off. The user has a choice of three printers in the configuration.

The first setting, attached-to-ansi, makes use of escape sequences on ANSI/VT100 terminals. It uses "<ESC>[5i" to begin directing all output sent to the terminal to the printer and then "<ESC>[4i" to return to normal. Alpine will send these escape sequences if the printer is set to attached-to-ansi. This works with most ANSI/VT100 emulators on Macs and PCs such as kermit, NCSA telnet, VersaTerm Pro, and WinQVT. Various terminal emulators implement the print feature differently. There is also a closely related method called attached-to-ansi-no-formfeed which is the same except for the lack of formfeed character at the end of the print job.

Attached-to-wyse and attached-to-wyse-no-formfeed are very similar to "attached-to-ansi". The only difference is in the control characters sent to turn the printer on and off. The Wyse version uses Ctrl-R for on, and Ctrl-T for off.

The second selection is the standard UNIX print command. The default is lpr, but it can be changed on a system basis to anything so desired in `/usr/local/lib/pine.conf`.

The third selection is the user's personal choice for a UNIX print command. The text to be printed is piped into the command. Enscript or lpr with options are popular choices. The actual command is retained even if one of the other print selections is used for a while.

Both the second and third sections are actually lists of possible commands rather than single commands.

If you have a PostScript printer attached to a PC or Macintosh, then you will need to use a utility called ansiprt to get printouts on your printer. Ansiprt source code and details can be found in the `./contrib` directory of the Alpine distribution.

## Save and Export

Alpine users get two options for moving messages in Alpine: Save and Export. Save is used when the message should remain ``in the Alpine realm.'' Saved messages include the complete header (including header lines normally hidden by Alpine), are placed in a Alpine folder collection and accumulate in a standard folder format which Alpine can read. In contrast, the Export command is used to write the contents of a message to a file for use outside of Alpine. Messages which have been exported are placed in the user's home directory (unless the feature use-current-dir is turned on), not in a Alpine folder collection. Unless FullHeaderMode is toggled on, all delivery-oriented headers are stripped from the message. Even with Export, Alpine retains message separators so that multiple messages can accumulate in a single file and subsequently be accessed as a folder. On UNIX systems, the Export command pays attention to the standard umask for the setting of the file permissions.

## Sent Mail

Alpine's default behavior is to keep a copy of each outgoing message in a special "sent mail" folder. This folder is also called the fcc for "file carbon copy". The existence, location and name of the sent mail folder are all configurable. Sent mail archiving can be turned off by setting the configuration variable default-fcc="". The sent mail folder is assumed to be in the default collection for Saves, which is the first collection named in folder-collections. The name of the folder can be chosen by entering a name in default-fcc. With PC-Alpine, this can be a bit complicated. If the default collection for Saves is local (DOS), then the default-fcc needs to be `SENTMAIL`, which is syntax for a DOS file. However, if the default collection for Saves is remote, then the default-fcc needs to be `sent-mail` to match the UNIX syntax.

The configuration variable fcc-name-rule also plays a role in selecting the folder to save sent mail in.

A danger here is that the sent mail could grow without bound. For this reason, we thought it useful to encourage the users to periodically prune their sent mail folder. The first time Alpine is used each month it will offer to archive all messages sent from the month before. Alpine also offers to delete all the sent mail archive folders which are more than 1 month old. If the user or system has disabled sent mail archiving (by setting the configuration variable default-fcc="") there will be no pruning question.

## Spell Checker

Both UNIX Alpine and PC-Alpine depend on the system for their spell checking and dictionary. Pico, the text editor, uses the same spell checking scheme as Alpine.

Lines beginning with ">" (usually messages included in replies) are not checked. The message text to be checked is on the standard input and the incorrect words are expected on the standard output.

The default spell checker is UNIX spell. You can replace this by setting the speller configuration variable. A common choice for a superior replacement is ispell.

PC-Alpine relies on the aspell library being installed. The library code can be obtained from http://aspell.net/win32/. It is fairly easy to install.

## Terminal Emulation and Key Mapping

UNIX Alpine has been designed to require as little as possible from the terminal. At the minimum, Alpine requires cursor positioning, clear to end of line, and inverse video. Unfortunately, there are terminals that are missing some of these such as a vt52. Alpine makes no assumptions as to whether the terminal wraps or doesn't wrap. If the terminal has other capabilities it may use some of them. Alpine won't run well on older terminals that require a space on the screen to change video attributes, such as the Televideo 925. One can get around this on some terminals by using "protected field" mode. The terminal can be made to go into protected mode for reverse video, and then reverse video is assigned to protected mode.

Alpine handles screens of most any size and resizing on the fly. It catches SIGWINCH and does the appropriate thing.

On the input side of things, Alpine uses all the standard keys, most of the control keys and (in function-key mode) the function keys. Alpine avoids certain control keys, specifically ^S, ^Q, ^H, and ^\ because they have other meanings outside of Alpine (they control data flow, etc.) ^H is treated the same as the delete key, so the backspace or delete keys always work regardless of any configuration. There is a feature compose-maps-delete-key-to-ctrl-d which makes the delete key behave like ^D rather than ^H (deletes current character instead of previous character).

Sometimes a communications program or communications server in between you and the other end will eat certain control characters. There is a work-around when you need it. If you type two escape characters followed by a character that will be interpreted as the character with the control key depressed. For example, ESC ESC T is equivalent to ^T.

When a function key is pressed and Alpine is in regular (non-function key) mode, Alpine traps escape sequences for a number of common function keys so users don't get an error message or have an unexpected command executed for each character in the function key's escape sequence. Alpine expects the following escape sequences from terminals defined as VT100:

> ANSI/VT100
> F1: <ESC>OP
> F2: <ESC>OQ
> F3: <ESC>OR
> F4: <ESC>OS
> F5: <ESC>Op
> F6: <ESC>Oq
> F7: <ESC>Or
> F8: <ESC>Os
> F9: <ESC>Ot
> F10: <ESC>Ou
> F11: <ESC>Ov

Arrow keys are a special case. Alpine has the escape sequences for a number of conventions for arrow keys hard coded and does not use termcap to discover them. This is because termcap is sometimes incorrect, and because many users have PC's running terminal emulators that don't conform exactly to what they claim to emulate. There is a feature called termdef-takes-precedence which can be set to cause the termcap or terminfo definitions to be used instead of the built in definitions. Some arrow keys on old terminals send single control characters like ^K (one even sends ^\). These arrow keys will not work with Alpine. The most popular escape sequences for arrow keys are:

> Up: <ESC>[A <ESC>?x <ESC>A <ESC>OA
> Down: <ESC>[B <ESC>?r <ESC>B <ESC>OB
> Right: <ESC>[C <ESC>?v <ESC>C <ESC>OC
> Left: <ESC>[D <ESC>?t <ESC>D <ESC>OD