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.
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 (for example: spaces, commas, "@", ...).
The fullname field is usually stored as Last_name, First_name, in order that a sort on the fullname field comes out right. If there is a comma in the fullname, Pine 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 the email-address part of the address, i.e., the part that goes inside the brackets (<>). It is combined with the fullname field to form the complete address. For a distribution list, the <address> is in the format:
"(" <address>, <address>, <address>, ... ")"
Unlike the simple entry case, each of the addresses in a list can be a full RFC 822 address with fullname included, or it may be just the same as in the simple case. This way you can 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 this is detected and flagged. 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. Neither the fcc nor the comments field is normally shown on the screen in the address book screen. You can only see them by Editing them. You may also search them with the WhereIs command.
The address book is displayed in the order that it is sorted in the file. When the user chooses a different sorting criterion, the file is actually sorted, not just the view of the file.
When the address book is written out, it is first written to a temporary file and if that write is successful it is renamed correctly. This guards against errors writing the file that might destroy the whole address book. The address book is re-written after each change.
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 Pine can read either format, so it should be possible to share a read-only address book among the two populations (using NFS, for example). The end-of-line character for the LookUp file is always just <LF>, even on a PC. There is not currently any method built into Pine to access a remote address book (through IMAP or something like that). The only sharing possible is via some external remote file system or copying. It is very likely that a future version of Pine will be able to access remote address books using IMSP, when that becomes standardized and available.
The lookup file changes whenever the address book itself is changed. If it doesn't exist, Pine attempts to create it. If Pine doesn't have permission to create the lookup file with the standard name, it will create a temporary version in a temp directory. You want to avoid this since it would have to be rebuilt every time Pine was run, and rebuilding takes a significant time for a large address book. So, if you're going to have a shared address book in a read-only directory, it is highly desirable to create the lookup file so that the users sharing it won't have to each create a copy in a temp directory. You can do that by running Pine and accessing the address book under a user id which does have permission to write the file (root, for example) or by using the -create_lu command line argument to Pine (as root, still). If users may be using a shared address book that needs updating, it is best to move the old address book to another name rather than copying over it. It is also best to make the lookup file for the new addrbook before moving it and the address book file into place, otherwise users may get stuck initializing the new file.
An effort is made to detect that an address book has been changed by another process. If a change is detected, the address book will be closed down and a new open will be attempted. If the new lookup file is in place when the open is tried, it will work smoothly. In normal operation (lookups and browsing the address book) the check to see if it has changed is just a heuristic to notice if things seem right. It isn't more rigorous because it needs to be fast. When a lookup is done, an offset into the address book is gotten from the LookUp file and a seek into the address book is done. It will check to see if the preceding character is an end-of-line character, which it should be. If it isn't, it figures it needs to rebuild the LookUp file. When an address book is about to be changed, a more fool-proof check is made. Several things in the file are checked to see that it is a LookUp file (magic number, size, ...) and that it is whole. Then, a timestamp in the LookUp file is compared to the mtime of the address book. If the timestamp is later than the mtime, everything is ok, otherwise, the address book has been changed and the new change is aborted.
The address book code has been completely rewritten for 3.90 and production experience with shared address books is nil at the time of this writing. We expect there may be some changes as experience is gained, and that some new tools may emerge (scripts to convert password files to shared address books, for example).
PC-Pine creates a single debug file named PINEDEBG.TXT in the same directory as the PINERC file.
Design changes introduced in Pine 3.8x facilitate Pine users filtering email. You still have to get a filtering program and configure it correctly, but Pine now allows users to specify a set of incoming-folders. Pine will separate out all the folders listed as incoming-folders and offer convenient access to these. We hope that in the future Pine will be able to offer new message counts for all of the incoming folders.
PC-Pine reads and writes local (PC) folders in a special format similar to the Tenex format. Near as we can tell, PC-Pine is the only program to use this format. Beginning with version 3.90, PC-Pine includes a Read-Only driver for the Berkeley mailbox format in addition. That means that you can import Unix mail folders, or mount them via NFS or SMB, and PC-Pine can read them --but not modify them.
Extensions. In the past, file name extensions have been significant in both Unix Pine and PC-Pine, but this has caused more problems than it solved. Therefore, on Unix Pine extensions no longer have any special meaning, and this is the trend for PC-Pine as well.
By default, PC-Pine adds ".MTX" to the name of any local (PC) folders that are referenced, and suppresses the extension from the Folder List display. Now that PC-Pine can read more than one folder format, the MTX extension no longer implies a particular format, and is largely irrelevant. By using the "folder_extension" option, you can change this behavior. In particular, you may set "folder-extension" to the "null string" which tells PC-Pine to neither add nor hide-from-view *any* folder name extension.
The reason you might wish to over-ride the MTX default is that recent versions of PC-Pine have the ability to open (albeit READ-ONLY) normal Unix mail folders. Since it might be inconvenient to rename all of them to have an MTX extension, it is possible with this option to switch PC-Pine's behavior so that such folders can be seen and accessed without changing their names. However, doing this means that your existing PC-Pine local folders will have apparently changed their names. For example, if you had a local folder named "FOO" it will now appear in the Folder List as "FOO.MTX". If you wish to save additional messages to that folder, you will need to enter the full name, "FOO.MTX" at the Save prompt. Likewise for GOTO.
If you wish to permanently avoid having to deal with folder name extensions, you will need to set this option to the null string by entering two double- quote marks, and you will need to rename your existing local folders to not have an MTX extension. In DOS this can be done in one command, once you have changed to your mail directory: RENAME *.MTX *.
We don't know why you might wish to, but you could also use this option to tell PC-Pine to use an extension other than MTX. In this case, enter the three characters you desire to use in lieu of "MTX". Note that your existing folders will need to be renamed to correspond to this new extension.
From firstname.lastname@example.org Wed Aug 11 14:32:33 1993
You can fool Pine into thinking a file is a mail folder by copying a suitable message separator from a real folder to the beginning of the file and wherever you want message boundaries. The vast majority of INBOXes Pine reads and folders it writes are of this format.
dd-mmm-yyyy hh:mm:ss sssss,n;ffffffffffff
Punctuation is as given above.
The fields in the formats are:
dd two-digit day of month (leading space if a single-digit day)
mmm three-letter English month name (Jan, Feb, etc.)
yy two-digit year in 20th century (obsolete)
yyyy four-digit year
hh two-digit hour in 24-hour clock (leading zero if single-digit)
mm two-digit minute (leading zero)
ss two-digit second (leading zero)
zzz three-letter North American time zone (obsolete)
sssss signed four-digit international time zone as in RFC 822
n one or more digits of the size of the following message in
twelve-digit octal flags value
There are two standard locking mechanisms which handle program-contention locking. To be on the safe side, Pine implements both of them. The older mechanism places a file xxxx.lock (where xxxx is the name of the file being locked) in the same directory as the file being locked. This makes use of the fact that directory operations are atomic in UNIX and mostly works across NFS. There are involved algorithms used to determine if a lock has been held for an excessive amount of time and should be broken. The second program-contention locking mechanism uses the flock() system call on the mailbox. This is much more efficient and the locks can't get stuck because they go away when the process that created them dies. This is usually found on 4BSD and related machines.
In addition to these, Pine--through the c-client library--provides robust locking which prevents several users (or several instances of the same user) having a mail file open (for update) at once. This user-contention lock is held the entire time that the folder is in use.
With IMAPd 7.3(63) and Pine 3.84 and higher, the second Pine session which attempts to open a particular folder (usually INBOX) with Pine will ``win''and That is to say, the second session will have read/write access to the folder. The first user's folder will become read-only. (Note that this is exactly the opposite of the behavior prior to Pine 3.84 where the second open was read-only. Having the latest open be read-write seems to match more closely with what users would like to have happen in this situation.) Pine's additional locking is only effective against multiple uses of Pine or other programs using the c-client library, such as MailManager, ms, IMAPd and a few others. Beginning with Pine 3.85, there is an -o command line flag to intentionally open a mailbox read-only.
Pine locking on UNIX systems works by creating lock files in /tmp of the form \usr\spool\mail\joe. The system call flock() is then used on these files; the existence of the file alone does not constitute a lock. This lock is created when the folder is opened and destroyed when it is closed. When the folder is actually being written, the standard UNIX locks are also created.
If a folder is modified by some other program while Pine has it open, Pine will give up on that mail file, concluding it's best not to do any further reads or writes. This can happen if another mailer that doesn't observe Pine's user-contention locks (e.g. elm or mail) is run while Pine has the mail folder open. Pine checkpoints files every few minutes, so little data can be lost in these situations.
PC-Pine does not do any folder locking. It depends on IMAP servers to handle locking of remote folders. It is assumed that only one Pine session can be running on the PC at a time, so there is no contention issue around folders on the PC itself.
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.
This scheme can increase efficiency because Pine can be compiled to have the strings as part of shared, read-only text. Rather than each process having to read in the help text from a file, the strings are shared by all executing processes on the machine and demand paged. This works on machines that have separate instruction and data space, but is only fully implemented in the NeXT (tested) and Dynix (not tested) ports.
PC-Pine, which tries to run on machines with as little as 640k of memory, leaves the Pine help text out of the executable. PINE.EXE, PINE.HLP, and PINE.NDX are all needed for PC-Pine's help system.
When reading incoming email, Pine allows all character sets to pass through. Pine doesn't actually display the characters but simply passes them through; it is up to the actual display device to show the characters correctly. When composing email, Pine will accept input in any language and tag the message according to the character-set variable. Again, it is up to the input device to generate the correct sequences for the character set being used.
With the exception of UNICODE-1-1-UTF-7, the outgoing message is checked to see if it is all US-ASCII text (and contains no escape characters). In that case, the text will be labeled as US-ASCII even if the character-set variable is set to something else. The theory is that every reasonable character set will have US-ASCII as a subset, and that it makes sense to label the text with the lowest-common-denominator label so that more mailers will be able to display it. Text in the UNICODE-1-1-UTF-7 character set is never re-labelled as US-ASCII.
BUG: If you prepare a UNICODE-1-1 document and read it into the composer with ^R, Pine may mistreat it. If your document, when misviewed as 8-bit bytes, does not contain any individual bytes greater than 0x7f base 16, then pine will re-label your outgoing message as US-ASCII, even if your message is really in Unicode Cyrillic, Arabic, or Thai. On the other hand, if your UNICODE-1-1, when misviewed as 8-bit bytes, does contain at least one individual byte greater than 0x7f base 16, as is likely for Unicode French/German/Spanish, Greek, Japanese, and Chinese, then pine will retain the UNICODE-1-1 label.
The character sets are:
US-ASCII Standard 7 bit 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
KOI8-R 8 bit Latin and Russian
VISCII 8 bit Latin and Vietnamese
ISO-2022-JP Latin and Japanese
ISO-2022-KR Latin and Korean
UNICODE-1-1-UTF-7 Mail-safe Unicode
Earlier versions of Pine made use of the character set tags associated with text in MIME to decide if the text should be displayed or not. Depending on the character set tag and the character-set variable in Pine, the text was either displayed as is, displayed with some characters filtered out, or not displayed at all. The current version uses a much simpler algorithm in order to maximize the chance that useful contents are readable by the user. It simply displays all messages of type text and makes no attempt to filter out characters that may be in the wrong character set. If the text is tagged as something other than US-ASCII and the tag does not match the character set that the character-set variable is set to, then a warning is printed at the start of the message. In that case, it is possible that the text will be displayed incorrectly. For example, if the text is one variant of ISO-8859 and the display device is another variant, some of the characters may show up on the screen as the wrong character. Or if the text is Japanese and the display device is not, some parts of the message may be total gibberish (which will look like ASCII gibberish). On the other hand, the parts of the Japanese message that really are US-ASCII will be readable in the midst of the gibberish.
In the case of PC-Pine, the character values cannot be passed through to the display device unaltered since MS-DOS uses various non-standard character sets called "Code Pages".
The mapping between DOS Code Page and standard character set is controlled by the "character-set" variable in the PINERC file and the PC's installed Code Page. PC-Pine will automatically map common characters in IBM Code Pages 437, 850, 860, 863, and 865 to ISO-8859-1 and back when the PINERC has "character-set=ISO-8859-1". Pine will also map common characters for IBM Code Page 866 to ISO-8859-5 and back when "character-set=ISO-8859-5". The mappings are bi-directional, and applied to all saved text attachments in the defined character set, messages exported, etc.
Alternatively, the translation tables can be configured externally and applied at run time whenever the "character-set=" variable is set to something other then "US-ASCII" (the default). PC-Pine looks in the text file pointed to by the environment variable "ISO_TO_CP" for the table to use for mapping text matching the type defined by the "character-set=" variable into the local Code Page value. PC-Pine looks in the text file pointed to by the environment variable "CP_TO_ISO" for the table to use for mapping text in the local Code Page into outbound text tagged with the "character-set=" variable's value.
A text file containing a character set mapping table is expected to contain 256 elements where each element is a decimal number separated from the next element by white-space (space, tab or newline, but no commas!). The index of the element is the character's value in the source character set, and the element's value is the corresponding character's value in the destination character set.
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.
Starting with version 3.90, Pine 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 Pine 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, Pine will use that to look for one or more mailcap files, which are combined. In the absence of $MAILCAPS, Unix Pine will look for a personal mailcap file in ~/.mailcap and combine that with a system-wide file in /etc/mailcap. PC-Pine will look for a file named MAILCAP in the same directory as the PINERC file, and/or the directory containing the PINE.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 Pine sees a MIME message part tagged as type IMAGE, and Pine's image-viewer. configuration variable is set, Pine will attempt to send that attachment to the named image viewing program. In the case of UNIX Pine, 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, Pine 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 Pine 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 Pine will use its internal viewer to display it. This happens even if there is a mailcap description which matches this particular type. If it is labelled as having a character set other than the one you are using, it will still be displayed by the internal viewer (perhaps incorrectly), though you will get a warning message prepended to the message in the viewing screen. However, if you view a part of type "text/plain" from the ATTACHMENT INDEX screen, then Pine 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 Pine will select and display the one best suited. For parts of type "message/external-body", the parameters showing the retrieval method will be displayed, but the retrieval process is not yet automated. Messages of type "message/partial" are not currently supported.
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, Pine 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. Pine will recognize (and correctly label) a few special types including GIF, JPEG, PostScript, and some audio formats.
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 character-set variable. If an attachment is ASCII (no 8-bit characters) and contains no ESCAPE, ^N, or ^O characters (the characters used by some international character sets), 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 character-set variable.
All other attachments are unrecognized and therefore given the generic MIME label "application/octet-stream".
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 Pine, the notice will show the count of new messages and the sender of the most recent one.
Questions have arisen about the interaction between Pine and external mail notification routines (biff, csh, login). Firstly and unfortunately, we have found no PC based program that will check for email on an IMAP server when PC-Pine is not running. If you find one, please tell us.
The UNIX case is more complicated. Pine sets the modification and access time on a file every time it performs a write operation (status change or expunge). You need to see which of these your email notification program is looking at to know how it will behave with Pine.
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 Pine sessions try to access the same mail folder from different hosts without using IMAP. Imagine the scenario: Pine-A performs a write that changes the folder. Pine-B then attempts to perform a write on the same folder. Pine-B will get upset that the file has been changed from underneath it and abort operations on the folder. Pine-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 Pine-B session when this happens is the last few status changes.
If other mail readers besides Pine 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.
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>[6i" to return to normal. Pine 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. For example, NCSA telnet requires "capfile = PRN" in the config.tel file. Attached-to-ansi printing doesn't work at all with the telnet provided with PC-NFS.
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.
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 Pine distribution.
The three printer choices are for UNIX Pine only. PC-Pine for DOS can only print to the locally attached printer. All printing on PC-Pine (DOS) is done via ROM BIOS Print Services (Int 17h). After verifying the existence of a local printer via the BIOS Equipment-List Service (Int 11h), it simply sends the message text, character by character, to the first printer found using ASCII CR and LF at the end of lines and followed by an ASCII FF. Note, some system adjustments using the PC's "MODE" command may be required if the printer is not on the first parallel port. PC-Pine cannot generate PostScript, so printing to exclusively PostScript printers does not work.
PC-Pine for Winsock uses the MS-Windows printer interface. A Pine print command will bring up a standard MS-Windows printer dialog box.
The configuration variable fcc-name-rule also plays a role in selecting the folder to save sent mail in. See the documentation on it in the section on configuration variables.
The 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 Pine is used each month it will offer to archive all messages sent from the month before. Pine 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="") or if the fcc folder is a remote/IMAP folder then there will be no pruning question.
It is likely that Pine will be improved so that users can set the time increment for pruning (weekly, monthly, yearly, never) but that has not been implemented yet.
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 at compile time for the whole system. Pine also respects the environment variable SPELL. Beginning in Pine 3.92, there is also a "speller" configuration entry in the Setup/Config screen and configuration files. If it is set, Pine will use that as the spelling checker. The spelling checker reads its words from a standard dictionary on the system. Below is a description, contributed by Bob Hurt, of how you can create your own personal dictionary with additional ``correct'' words.
- Step 1:
- Make a file with all the words you want to include in your new dictionary. I did mine with one word per line in alphabetical order. Caps don't matter at all, as far as I know.
- Step 2:
- At the UNIX prompt, type "cat [word file] | spellin /usr/dict/hlista > [new dict name]" where [word file] is the file you just created and [new dict name] is the name of the new dictionary that Pine will look at instead of the standard /usr/dict/hlista. I named my word file .bobwords and my dictionary .bobspell so I don't have to see them when I do a ls command (ls doesn't list "dot" files). I also put the above command into my .alias file as the command makedict so I can add a word to my word file and easily recreate my dictionary. NOTE: the new dictionary is in something called a "hashed" format, and can't be read normally.
- Step 3:
- Check your new dictionary. At the UNIX prompt, type "cat [word file] | spellout [new dict name]" If you did everything correctly, it should just give you another prompt. If it lists any of the words in your file, something is wrong. I can try to help if all else fails.
- Step 4:
- Now you have to tell UNIX to use your dictionary instead of the standard one by setting the environment variable SPELL to access your dictionary. Go into your .login or .cshrc file in your home directory (it doesn't seem to make a difference which one you use) and add the linesetenv SPELL "spell -d [new dict name]"
- I also created an alias for SPELL in my .alias file so I can use the UNIX spell command to spell-check a file outside of Pine. (The .alias line is: alias spell 'spell -d [new dict name]')
- Step 5:
- Now you need to logoff and log back on to let UNIX look at your .login (or .cshrc) file.
Here is an alternative method suggested by Zachary Leber:
- Create a list (e.g. .zachwords) with the upper case followed by lower case words, sorted alphabetically.
- Add this line to .cshrc:setenv SPELL 'spell +/home/ie/rsa/.zachwords'
- The limitation here is that the path must be absolute (e.g. +~/.zachwords doesn't work).
- My man pages for spell show this + flag to be an easy way to do the exception list. This way you don't have to bother with hash lists or rehashing, and it seems to work across several platforms.
Pine handles screens of most any size and resizing on the fly. It catches SIGWINCH and does the appropriate thing. A screen one line high will display only the new mail notification. Screens that are less than ten columns wide don't format very nicely or work well, but will function fine again once resized to something large. Pine sets an internal maximum screen size (currently 170x200) and decides to use either termcap or terminfo when it is compiled.
On the input side of things, Pine uses all the standard keys, most of the control keys and (in function-key mode) the function keys. Pine avoids certain control keys, specifically ^S, ^Q, ^H, and ^\ because they have other meanings outside of Pine (they control data flow, etc.) ^H is treated the same as the delete key, so the backspace or delete keys always works regardless of any configuration. In an upcoming version, there will be an option to have the delete key behave like ^D rather than ^H.
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 Pine is in regular (non-function key) mode, Pine 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. Pine expects the following escape sequences from terminals defined as VT100:
Arrow keys are a special case. Pine 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. Some arrow keys on old terminals send single control characters like ^K (one even sends ^\). These arrow keys will not work with Pine. 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
It is possible to configure an NCD X-terminal so that some of the special keys operate. Brad Greer contributes these instructions:
Pine*VT100.Translations: #override \n\
<Key>Delete: string(0x04) \n\
<Key>End: string(0x05) \n\
<Key>Escape: string(0x03) \n\
<Key>Home: string(0x01) \n\
<Key>Next: string(0x16) \n\
<Key>Prior: string(0x19) \n\
<Key>KP_Enter: string(0x18) \n\