/usr/local/lib/pine.conf
or /usr/local/lib/pine.conf.fixed.
(Actually, these files are whatever the definitions for
SYSTEM_PINERC and SYSTEM_PINERC_FIXED
in pine/osdep/os-xxx.h are set to.)
The location of the pine.conf file can be changed with the -P command line
argument.
Both Pine
and PC-Pine also use personal (user-based) configuration files.
On UNIX machines, the personal configuration file is the
file ~/.pinerc.
For PC-Pine systems, the personal configuration file is in
$PINERC or <PineRC registry value> or
${HOME}\PINE\PINERC or
<PINE.EXE dir>\PINERC.
Or the personal configuration file can be specified with the -p command
line argument.
After the personal configuration, Pine may optionally use
a personal exceptions configuration file which is specified with the
command line option "-x exceptions_config".
"Exceptions_config" may be either a local file or a remote
configuration folder.
For Unix Pine, if you don't have a "-x" command line option,
Pine will look for the file ".pinercex"
in the same local directory that the regular config file is located in.
If the regular config file is remote then Unix Pine looks in the home
directory for ".pinercex".
For PC-Pine, if you don't have a "-x" command line option,
PC-Pine will use the value of the
environment variable $PINERCEX.
If that is not set, PC-Pine will look for
the local file "PINERCEX"
in the same local directory that the regular config file is located in.
If the regular config file is remote then PC-Pine looks in the
local directory specfied by the "-aux local_directory" command
line argument, or the directory ${HOME}\PINE, or
in <PINE.EXE directory>.
The syntax of a non-list configuration variable is this:
<variable> = <value>If the value is absent then the variable is unset. To set a variable to the empty value the syntax is "". This is equivalent to an absent value except that it overrides any system-wide value that may be set. Quotes may be used around any value. All values are strings and end at the end of the line or the closing quote. Leading and trailing space is ignored unless it is included in the quotes. There is one variable, use-only-domain-name, for which the only appropriate values are yes and no. That's because it is a variable from the early days of Pine before features existed.
There is also a second type of variable, lists. A list is a comma-separated list of values. The syntax for a list is:
<variable> = <value> [, <value> , ... ]A list can be continued on subsequent lines by beginning the line with white-space. Both the per-user and global configuration files may contain comments which are lines beginning with a
#. For UNIX Pine, there are five ways in which each variable can be set. In decreasing order of precedence they are:
If the variable is not set in any of those places, there is a default setting in the source code.
So, system-wide fixed settings always take precedence over command line flags, which take precedence over per-user exception settings, which take precedence over per-user settings, which take precedence over system-wide configuration settings. PC-Pine has the same list, except that it does not use a system-wide fixed configuration file. This can be modified slightly by using inheritance, which is covered below.
You may get a sample/fresh copy of the system configuration file by running Pine -conf. The result will be printed on the standard output with short comments describing each variable. (The online help in the Setup screens provides longer comments.) If you need to fix some of the configuration variables, you would use the same template for the fixed configuration file as for the regular system-wide configuration file. (If it isn't clear, the purpose of the fixed configuration file is to allow system administrators to restrict the configurability of Pine. It is by no means a bullet-proof method.) Pine will automatically create the personal configuration file the first time it is run, so there is no need to generate a sample. Pine reads and writes the personal configuration file occasionally during normal operation. Users will not normally look at their personal configuration file, but will use the Setup screens from within Pine to set the values in this file. If a user does add additional comments to the personal configuration file they will be retained.
References to environment variables may be included in the Pine
configuration files. The format is $variable or
${variable}. The character ~ will be expanded to the
$HOME environment variable.
For a more complete explanation of how environment variables work, see
the section
Using Environment Variables.
When environment variables are used for Pine settings which take lists, you must have an environment variable set for each member of the list. That is, Pine won't properly recognize an environment variable which is set equal to a comma-delimited list. It is OK to reference unset environment variables in the Pine configuration file, which will expand to nothing.
Beginning with Pine 4.30 you can use the command line option "-x config" to split your configuration into generic and exceptional pieces. Config may be either local or remote.
For most people, splitting the configuration information into two pieces is only going to be useful if the generic information is accessed remotely. If you already have a local pinerc file with settings you like you may find that the command Setup/RemoteConfigSetup will be useful in helping you convert to a remote configuration. The command line flag copy_pinerc may also be useful.
For configuration variables which are lists, like "smtp-server" or "incoming-folders", the inheritance mechanism makes it possible to combine the values of options from different configuration locations instead of replacing the value. Configuration Inheritance has more information about how inheritance is used.
In the default INDEX display the personal name (or email address) of the person listed in the message's "From:" header field is usually displayed except when that address is yours or one of your alternate addresses. In that case you will usually see the name of the first person specified in the message's "To:" header field with the prefix "To: " prepended.
With respect to Reply, the Reply to All option will exclude addresses listed here.
This variable may be set to any of the following values:
where the color_number is an ASCII digit between 0 and 7. The numbers 0 through 7 should correspond to the colors black, red, green, yellow, blue, magenta, cyan, and white. Some terminal emulators use a pre-ANSI scheme which swaps the colors blue and red and the colors yellow and cyan. This will cause the default colors to be different, but other than that things should work fine. The escape sequences used to set the background colors are the same as for the foreground colors except a "4" replaces the "3".
Note: With the Tera Term terminal emulator this setting works well. You should also have the Tera Term "Full color" option turned OFF. You may find the "Full color" option in Tera Term's "Setup" menu, in the "Window" submenu.
The normal default is "no-color".
Once you've turned on color you may set the colors of many objects on the screen individually. The Color Configuration section has more information, or you may just try it by running the "Setup" command and typing "K" for Kolor to enter the color configuration screen (Kolor instead of Color because C means Config). Most categories of color which Pine supports are configurable there. Index line color is configured separately.
Beginning with Pine 4.41, the default names of some colors were changed in order to have better interoperability between PC-Pine and Unix Pine with both eight and 16-color terminals. Both PC-Pine and 8-color Unix Pine will interpret the colors named color008, color009, ..., color015 as black, red, ..., white. When changing a configuration color they will put the colors black, color009, color010, ..., color015 into the config file. That is, the colors red, green, ..., white will only appear in the config file if put there manually or if they were already there from an older version of Pine. The reason for this is because with 16-color xterm the colors red, green, ..., white are actually two-thirds intensity colors, and the colors color009, color010, ..., color015 (in pine terminology) are full intensity colors which better match the default eight of PC-Pine or 8-color Unix terminal emulators. The idea is that you can use the eight colors of an 8-color terminal on a 16-color terminal and with PC-Pine. Those eight colors will be about the same in all three situations.
In pre-4.41 PC-Pine the three default grays offered were called color008, color009, and color010. Since this conflicts with three of the colors on 16-color terminals these three colors have been renamed colorlgr, colormgr, and colordgr. PC-Pine will attempt to automatically change those color names the first time you run a version higher than 4.40. If that fails for some reason, you will see your old light grays displayed as black, your old medium grays displayed as red, and your old dark grays displayed as green. You may fix these from within the PC-Pine color config screens. If you then go back to running a pre-4.41 version of PC-Pine the colors with the new names (colorlgr...) will show up as Normally colored text.
and another showing how you might set a Reply-To address
You may also set non-standard header values here. For example, you could add
or even
If you include a value after the colon then that header will be included in your outgoing messages unless you delete it before sending. If a header in the Customized-Headers list has only a tag but no value, then it will not be included in outgoing messages unless you edit a value in manually. For example, if
is in the list, then the Reply-To header will be available for editing but won't be included unless a value is added while in the composer.
It's actually a little more complicated than that. The values of headers that you set with the Customized-Headers option are defaults. If the message you are about to compose already has a value for a header, that value is used instead of a value from your Customized-Headers. For example, if you are Replying to a message the Subject field will already be filled in. In that case, if the Customized-Headers list contains a Subject line, the custom subject will NOT be used. The subject derived from the subject of the message you are Replying to will be used instead.
It is also possible to make header setting even more complicated and more automatic by using Roles, but if all you want to do is set a default value for a header, you don't need to think about Roles.
If you change your From address you may also find it useful to add the changed From address to the alt-addresses configuration option.
Because commas are used in the configuration file to separate the list of Customized-Hdrs, you need to quote the value if that value contains a comma. Use double quotes and place the quotes around the entire value part of the header, not including the name of the header. For example, you might have
as one of the Customized-Hdrs.
If you set this option to a value higher than one, then that many copies of dead letter files will be saved. For example, if you set this option to "3" then you may have files named "DEADLETR", "DEADLETR2", and "DEADLETR3"; or "dead.letter", "dead.letter2", and "dead.letter3". In this example, the most recently cancelled message will be in "dead.letter", and the third most recently cancelled message will be in "dead.letter3". The fourth most recently cancelled message will no longer be saved.
If you set this option to zero, then NO record of canceled messages is maintained.
If the feature Quell-Dead-Letter-On-Cancel is set, that overrides whatever you set for this option. If this option had existed at the time, then the Quell feature would not have been added, but it is still there for backwards compatibility. So, in order for this option to have the desired effect, make sure the Quell feature is turned off.
Note that the "Newsgroups:" header will be abbreviated in the Composer display, but should be spelled out in full here.
is used by Pine. If you want to try turning it off, setting this feature will turn it off. This part of the locale has to do with the sort order of characters in your locale. A related feature is enable-setlocale-ctype.
The mbox driver enables the following behavior: if there is a
file called mbox
in your home directory, and if that file is either empty or in Unix mailbox
format, then every time you open INBOX the mbox driver
will automatically transfer mail from the system mail spool directory into the
mbox file and
delete it from the spool directory. If you disable the mbox driver,
this will not happen.
It is not recommended to disable the driver which supports the system default mailbox format. On most non-SCO systems, that driver is the unix driver. On most SCO systems, it is the mmdf driver. The system default driver may be configured to something else on your system; check with your system manager for additional information.
It is most likely not very useful for you to disable any of the drivers other than possibly mbox. You could disable some of the others if you know for certain that you don't need them but the performance gain in doing so is very modest.
Pine matches its list of supported authenticators with the server to determine the most secure authenticator that is supported by both. If no matching authenticators are found, Pine will revert to plaintext login (or, in the case of SMTP, will be unable to authenticate at all).
The candidates for disabling are listed below. There may be more if you compile Pine with additional authenticators and/or a newer version of the c-client library.
Normally, you will not disable any authenticators. There are two exceptions:
It is never necessary to disable authenticators, since Pine will try other authenticators before giving up. However, disabling the relevant authenticator avoids annoying error messages.
Display filters do not work with PC-Pine.
The command is executed and the message is piped into its standard input. The standard output of the command is read back by Pine. The _TMPFILE_ token (see below) overrides this default behavior.
The filter's use is based on the configured trigger string. The format of a filter definition is:
You can specify as many filters as you wish, separating them with a comma. Each filter can have only one trigger and command. Thus, two trigger strings which invoke the same command require separate filter specifications.
The trigger is simply text that, if found in the message, will invoke the associated command. If the trigger contains any space characters, it must be placed within quotes. Likewise, should you wish a filter to be invoked unconditionally, define the trigger as the null string, "" (two consecutive double-quote characters). If the trigger string is found anywhere in the text of the message the filter is invoked. Placing the trigger text within the tokens defined below changes where within the text the trigger must be before considering it a match.
Trigger Modifying Tokens:
The "command" and "arguments" portion is simply the command line to be invoked if the trigger string is found. Below are tokens that Pine will recognize and replace with special values when the command is actually invoked.
Command Modifying Tokens:
The feature disable-terminal-reset-for-display-filters is related.
Performance caveat/considerations:
Testing for the trigger and invoking the filter doesn't come for free.
There is overhead associated with searching for the trigger string, testing
for the filter's existence and actually piping the text through the filter.
The impact can be reduced if the Trigger Modifying Tokens above are
employed.
Limitation:
If Header Colors are being used, the sequences of bytes which indicate
color changes will be contained in the text which is passed to the
display-filter.
If this causes problems you'll need to turn off Header Colors.
The thirteen bytes which indicate a color change are
the character \377 followed by
\010 for a foreground color or \011 for a background color.
Then comes eleven characters of RGB data which looks something like
255, 0,255, depending on the particular color, of course.
Normally, when a filename is supplied that lacks a leading "path" component, Pine assumes the file exists in the user's home directory. Under Windows operating systems, this definition isn't always clear. This feature allows you to explictly set where Pine should look for files without a leading path.
NOTE: this feature's value is ignored if either use-current-dir feature is set or the PINERC has a value for the operating-dir variable.
.MTX by default.
There are some situations where automatic new-mail checking does not work. For example, if a mail folder is opened using the POP protocol or a newsgroup is being read using the NNTP protocol, then new-mail checking is disabled.
It may be possible to check for new mail in these cases by reopening the folder. Pine does not do this for you automatically, but you may do the commands manually to cause this to happen. You reopen by going back to the folder list screen from the message index screen with the "<" command, and then going back into the message index screen with the ">" command. (Actually, any method you would normally use to open a folder will work the same as the "<" followed by ">" method. For example, the GoTo Folder command will work, or you may use L to go to the Folder List screen and Carriage Return to reopen the folder.)
There are some cases where Pine knows that reopening the folder should be useful as a way to discover new mail. At the time of this writing, connections made using the POP protocol, news reading using the NNTP protocol, local news reading, and local ReadOnly folders which are in the traditional UNIX or the MMDF format all fall into this category. There are other cases where it may be a way to discover new mail, but Pine has no way of knowing, so it might also just be an exercise in futility. All remote, ReadOnly folders other than those listed just above fall into this category. The setting of this option together with the type of folder controls how Pine will react to the apparent attempt to reopen a folder.
If you don't reopen, then you will just be back in the message index with no change. You left the index and came back, but the folder remained "open" the whole time. However, if you do reopen the folder, the folder is closed and then reopened. In this case, the current state of the open folder is lost. The New status, Important and Answered flags, selected state, Zoom state, collapsed or expanded state of threads, current message number, and any other temporary state is all lost when the reopen happens. For POP folders (but not NNTP newsgroups) the Deleted flags are also lost.
In the possibilities listed below, the text says "POP/NNTP" in several places. That really implies the case where Pine knows it is a good way to discover new mail, which is more than just POP and NNTP, but POP and NNTP are the cases of most interest. This option probably has more possible values than it deserves. They are:
Remember, wherever it says POP or NNTP above it really means POP or NNTP or any of the other situations where it is likely that reopening is a good way to discover new mail.
There is an alternative that may be of useful in some situations. Instead of manually checking for new mail you can set up a Mail Drop and automatically check for new mail.
Nickname | Fullname | Addresswith optional whitespace in all the obvious places.
Setting this variable will alter Pine's usual behavior when you execute the Compose command. Normally, Pine offers a chance to continue a postponed or interrupted message should one or the other exist. When this variable is set to a folder name that exists, Pine will also offer the chance to select a message from the folder to insert into the composer, much like when continuing a postponed message. The difference, however, is that Pine will not automatically delete the selected message from the Form Letter Folder.
Setting this variable will also affect Pine's behavior when you Postpone a message from the composer. Normally, Pine simply stashes the message away in your Postponed-Folder. Regardless of the specified folder's existence, Pine will ask which folder you intend the message to be stored in. Choose the "F" option to store the message in your Form Letter Folder. This is the most common way to add a message to the folder.
Another method of adding messages to the folder is via the Pine composer's Fcc: field. If you are sending a message that you expect to send in the same form again, you can enter the Form Letter Folder's name in this field. Pine, as usual, will copy the message as it's sent. Note, when you later select this message from your Form Letter Folder, it will have the same recipients as the original message.
To delete a message from the Form Letter Folder, you can either select the folder from a suitable FOLDER LIST screen, or use the Delete command in the MESSAGE INDEX offered when selecting from the folder as part of the Compose command. You can delete a Form Letter Folder just as any other folder from a suitable FOLDER LIST screen.
You may find that the Roles facility introduced in Pine 4.10 can be used to replace the Form Letter Folder.
If these are not path names, they will be in the default collection for Saves. Any valid folder specification, local or remote (via IMAP), is allowed. There is no default.
Pine provides a pre-defined set of informational fields with reasonable column widths automatically computed. You can, however, replace this default set by listing special tokens in the order you want them displayed.
The list of available tokens is here.
Spaces are used to separate listed tokens. Additionally, you can specify how much of the screen's width the taken's associated data should occupy on the index line by appending the token with a pair of parentheses enclosing either a number or percentage. For example, "SUBJECT(13)" means to allocate 13 characters of space to the subject column, and "SUBJECT(20%)" means to allocate 20% of the available space to the subjects column, while plain "SUBJECT" means the system will attempt to figure out a reasonable amount of space.
There is always one space between every pair of columns, so if you use fixed column widths (like 13) you should remember to take that into account. Several of the fields are virtually fixed-width, so it doesn't make much sense to specify the width for them. The fields STATUS, FULLSTATUS, IMAPSTATUS, MSGNO, the DATE fields, SIZE, and DESCRIPSIZE all fall into that category. You may specify widths for those if you wish, but you're probably better off letting the system pick those widths.
The default is equivalent to:
This means that the four fields without percentages will be allocated first, and then 33% and 67% of the remaining space will go to the from and subject fields. If one of those two fields is specified as a percentage and the other is left for the system to choose, then the percentage is taken as an absolute percentage of the screen, not of the space remaining after allocating the first four columns. It doesn't usually make sense to do it that way. If you leave off all the widths, then the subject and from fields (if both are present) are allocated space in a 2 to 1 ratio, which is almost exactly the same as the default.
What you are most likely to do with this configuration option is to specify which fields appear at all, which order they appear in, and the percentage of screen that is used for the from and subject fields if you don't like the 2 to 1 default.
Keywords may be used when Selecting messages (Select Keyword). You will need to enable the enable-aggregate-command-set option to use Select. Keywords may also be used in the Patterns of Rules (Filters, Indexcolors, etc). Filter rules may be used to set keywords automatically. Keywords may be displayed as part of the Subject of a message by using the SUBJKEY or SUBJKEYINIT tokens in the Index-Format option. The Keyword-Surrounding-Chars option may be used to modify the display of keywords using SUBJKEY and SUBJKEYINIT slightly. Keywords may also be displayed in a column of their own in the MESSAGE INDEX screen by using the KEY or KEYINIT tokens. It is also possible to color keywords in the index using the Setup/Kolor screen (Keyword Colors). Keywords are not supported by all mail servers.
You may give keywords nicknames if you wish. If the keyword definition you type in contains a SPACE character, then the actual value of the keyword is everything after the last SPACE and the nickname for that keyword is everything before the last SPACE. For example, suppose you are trying to interoperate with another email program which uses a particular keyword with an unpleasant name. Maybe it uses a keyword called
but for you that keyword means that the message is work-related. You could define a keyword to have the value
and then you would use the name "Work" when dealing with that keyword in Pine. If you defined it as
the nickname would be everything before the last SPACE, that is the nickname would be "My Work".
Some commonly used keywords begin with dollar signs. This presents a slight complication, because the dollar sign is normally used to signify environment variable expansion in the Pine configuration. In order to specify a keyword which begins with a dollar sign you must precede the dollar sign with a second dollar sign to escape its special meaning. For example, if you want to include the keyword
as one of your possible keywords, you must enter the text
instead.
and the SUBJKEYINIT token would look like
The default character before the keywords is the left brace ({) and the default after the keywords is the right brace followed by a space (} ).
This option allows you to change that. You should set it to two values separated by a space. The values may be quoted if they include space characters. So, for example, the default value could be specified explicitly by setting this option to
The first part wouldn't need to be quoted (but it doesn't hurt). The second part does need the quotes because it includes a space character. If you wanted to change the braces to brackets you could use
Inside the quotes you can use backslash quote to mean quote, so
would produce
It is also possible to color keywords in the index using the Setup/Kolor screen (Keyword Colors).
It is not possible to change the fact that a space character is used to separate the keywords if more than one keyword is set for a message. It is also not possible to change the fact that there are no separators between the keyword initials if more than one keyword is set.
Theserver_name[:port]"quoted stuff"
server_name is just a hostname and it is followed by
an optional colon and port number. The default port is 389.
Following the server name is a single SPACE character followed by
a bunch of characters inside double quotes. The part inside the quotes is
a set of tag = value pairs.
Each tag is preceded by a slash (/) and followed
by an equal sign. The value for that tag is the text up to the next slash.
An example of some quoted stuff is:
This would set the search base for this server to"/base=o=University of Washington, c=US/impl=0/.../nick=My Server"
o=University of Washington, c=US, set the implicit bit to zero,
and set the nickname for the server to My Server.
All of the tags correspond directly to items in the Setup/Directory screen
so experiment with that if you want to see what the possible tags and values
are.
This is simply a different way to store the signature data. The signature is stored inside your Pine configuration file instead of in a separate signature file. Tokens contained in the signature work the same way they do with the regular signature-file.
The Setup/Signature command in Pine's Main Menu will edit the literal-signature by default. However, if no literal-signature is defined and the file named in the signature-file option exists, then the latter will be used instead. Compose (Reply, Forward, ...) will default to using the literal-signature if defined, otherwise it will use the contents of the file named in signature-file.
The Pine composer is used to edit the literal-signature. The result of that edit is first converted to a C-style string before it is stored in the configuration file. In particular, the two character sequence \n (backslash followed by the character "n") will be used to signify a line-break in the signature. You don't have to enter the \n, but it will be visible in the SETUP CONFIGURATION window after you are done editing the signature.
There are some situations where automatic new-mail checking does not work. See the discussion about new-mail checking in folder-reopen-rule.
The new-mail checking will not happen exactly at the frequency that you specify. For example, Pine may elect to defer a non-INBOX mail check if you are busy typing. Or, it may check more frequently than you have specified if that is thought to be necessary to keep the server from closing the connection to the folder due to inactivity. If Pine checks for new mail as a side effect of another command, it will reset the timer, so that new-mail checking may seem to happen irregularly instead of every X seconds like clockwork.
If you are anxious to know about new mail as soon as possible, set the check interval low, and you'll know about the new mail by approximately that amount of time after it arrives. If you aren't so worried about knowing right away, set this option to a higher value. That will save the server some processing time and may save you some of the time you spend waiting for new-mail checks to happen if you are dealing with a slow server or slow network connection.
If you suspect that new-mail checking is causing slow downs for you, you may want to look into the options Quell-Mailchecks-Composing-Except-Inbox, Quell-Mailchecks-Composing-Inbox and Mail-Check-Interval-Noncurrent, which refine when mail checking is done.
If the mailbox being check uses a Mail Drop then there is a minimum time (maildrop-check-minimum) between new-mail checks. Because of this minimum you may notice that new mail does not appear promptly when you expect it. The reason for this is to protect the server from over-zealous opening and closing of the Mail Drop folder, since that is a costly operation.
A side effect of disabling mail checking is that there will be situations in which the user's IMAP connection will be broken due to inactivity timers on the server. Another side effect is that the user-input-timeout option won't work.
Normally this option is set to zero, which means that the value used will be the same as the value for the "Mail-Check-Interval". If you set this option to a value different from zero (usually larger than the value for "Mail-Check-Interval") then that is the check interval that will be used for folders which are not the currently open folder or the INBOX. You may not even have any folders that are noncurrent and not the INBOX. If you do, it is likely that they are due to Stay-Open-Folders you have configured. This option also affects the rate of mail checking done on cached connections to folders you previously had open but are no longer actively using. You aren't expected to understand that last sentence, but if you are interested take a look at Max-Remote-Connections, and the related options.
This option specifies, in seconds, the minimum time between Mail Drop new-mail checks. You may want to set this minimum high in order to avoid experiencing some of the delays associated with the checks. Note that the time between checks is still controlled by the regular Mail-Check-Interval option. When Pine is about to do an automatic check for new mail (because the Mail-Check-Interval has expired) then if the time since the last new-mail check of any open Mail Drops has been greater than the MailDrop-Check-Minimum, the Mail Drop is checked for new mail as well. Therefore, it is only useful to set this option to a value that is higher than the Mail-Check-Interval.
If this option is set to zero, automatic Mail Drop new-mail checking is disabled. There is a minimum value, normally 60 seconds. The default value is normally 60 seconds as well. This applies to the INBOX and to the currently open folder if that is different from the INBOX.
There are some time costs involved in opening and closing remote IMAP folders, the main costs being the time you have to wait for the connection to the server and the time for the folder to open. Opening a folder may involve not only the time the server takes to do its processing but time that Pine uses to do filtering. These times can vary widely. They depend on how loaded the server is, how large the folder being opened is, and how you set up filtering, among other things. Once Pine has opened a connection to a particular folder, it will attempt to keep that connection open in case you use it again. In order to do this, Pine will attempt to use the Max-Remote-Connections (the value of this option) IMAP connections you have alloted for this purpose.
For example, suppose the value of this option is set to "2". If your INBOX is accessed on a remote server using the IMAP protocol, that doesn't count as one of the remote connections but it is always kept open. If you then open another IMAP folder, that would be your first remote connection counted as one of the Max-Remote-Connections connections. If you open a third folder the second will be left open, in case you return to it. You won't be able to tell it has been left open. It will appear to be closed when you leave the folder but the connection will remain in the background. Now suppose you go back to the second folder (the first folder after the INBOX). A connection to that folder is still open so you won't have to wait for the startup time to open it. Meanwhile, the connection to the third folder will be left behind. Now, if you open a fourth folder, you will bump into the Max-Remote-Connections limit, because this will be the third folder other than INBOX and you have the option set to "2". The connection that is being used for the third folder will be re-used for this new fourth folder. If you go back to the third folder after this, it is no longer already connected when you get there. You'll still save some time since Pine will re-use the connection to the fourth folder and you have already logged in on that connection, but the folder will have to be re-opened from scratch.
If a folder is large and the startup cost is dominated by the time it takes to open that folder or to run filters on it, then it will pay to make the value of this option large enough to keep it open. On the other hand, if you only revisit a handful of folders or if the folders are small, then it might make more sense to keep this number small so that the reconnect time (the time to start up a new connection and authenticate) is eliminated instead.
You may also need to consider the impact on the server. On the surface, a larger number here may cause a larger impact on the server, since you will have more connections open to the server. On the other hand, not only will you be avoiding the startup costs associated with reopening a folder, but the server will be avoiding those costs as well.
When twenty five minutes pass without any active use of an IMAP connection being saved for possible re-use, that connection will be shut down,
You may have Pine create a FIFO special file (also called a named pipe, see mkfifo(3) and fifo(4)) where it will send a one-line message each time a new message is received in the current folder, the INBOX, or any open Stay-Open-Folders. To protect against two different Pines both writing to the same FIFO, Pine will only create the FIFO and write to it if it doesn't already exist.
A possible way to use this option would be to have a separate window on your screen running the command
where "filename" is the name of the file given for this option. Because the file won't exist until after you start Pine, you must first start Pine and then run the "cat" command. You may be tempted to use "tail -f filename" to view the new mail log. However, the common implementations of the tail command will not do what you are hoping.
The width of the messages produced for the FIFO may be altered with the NewMail-Window-Width option.
On some systems, fifos may only be created in a local filesystem. In other words, they may not be in NFS filesystems. This requirement is not universal. If the system you are using supports it, it should work. (It is often the case that your home directory is in an NFS filesystem. If that is the case, you might try using a file in the "/tmp" filesystem, which is usually a local filesytem.) Even when it is possible to use an NFS-mounted filesystem as a place to name the fifo (for example, your home directory), it will still be the case that the reader (probably the "cat" command) and the writer (Pine) of the fifo must be running on the same system.
This option is only useful if you have turned on the NewMail-FIFO-Path option. That option causes new mail messages to be sent to a fifo file. Those messages will be 80 characters wide by default. You can change the width of the messages by changing this option. For example, if you are reading those messages in another window you might want to set this width to the width of that other window.
For UNIX Pine, this option is only useful if you have turned on the NewMail-FIFO-Path option. That option causes new mail messages to be sent to a fifo file. Those messages will be 80 characters wide by default. You can change the width of those messages by changing this option. For example, if you are reading those messages in another window you might want to set this width to the width of that other window.
If you are using PC-Pine, it has an option in the Config menu to turn on the "New Mail Window". The present option also controls the width of that window.
/usr/lib/news/active.
/usr/spool/news.
When you open a connection to a News server using the NNTP protocol, you normally have access to all of the articles in each newsgroup. If a server keeps a large backlog of messages it may speed performance some to restrict attention to only the newer messages in a group. This option allows you to set how many article numbers should be checked when opening a newsgroup. You can think of "nntp-range" as specifying the maximum number of messages you ever want to see. For example, if you only ever wanted to look at the last 500 messages in each newsgroup you could set this option to 500. In actuality, it isn't quite that. Instead, for performance reasons, it specifies the range of article numbers to be checked, beginning with the highest numbered article and going backwards from there. If there are messages that have been canceled or deleted their article numbers are still counted as part of the range.
So, more precisely, setting the "nntp-range" will cause article numbers
to be considered when reading a newsgroup. The number of messages that show up in your index will be less than or equal to the value of "nntp-range".
The purpose of this option is simply to speed up access when reading news. The speedup comes because Pine can ignore all but the last nntp-range article numbers, and can avoid downloading any information about the ignored articles. There is a cost you pay for this speedup. That cost is that there is no way for you to see those ignored articles. The articles that come before the range you specify are invisible to you and to Pine, as if they did not exist at all. There is no way to see those messages using, for example, an unexclude command or something similar. The only way to see those articles is to set this option high enough (or set it to zero) and then to reopen the newsgroup.
If this option is set to 0 (which is also the default), then the range is unlimited. This option applies globally to all NNTP servers and to all newsgroups on those servers. There is no way to set different values for different newsgroups or servers.
When you define an NNTP server, Pine implicitly defines a news collection for you, assuming that server as the news server and assuming that you will use the NNTP protocol and a local newsrc configuration file for reading news. See also Configuring News.
Your NNTP server may offer NNTP "AUTHINFO SASL" or "AUTHINFO USER" authentication. It may even require it. If your NNTP server does offer such authentication you may specify a user name parameter to cause Pine to attempt to authenticate. The same is true for the server name in a folder collection which uses NNTP. This parameter requires an associated value, the username identifier with which to establish the server connection. An example might be:
If authentication is offered by the server, this will cause Pine to attempt to use it. If authentication is not offered by the server, this will cause Pine to fail with an error similar to:
For more details about the server name possibilities see Server Name Syntax.
/etc/passwd).
The easiest way to change the full From address is with the
customized-hdrs variable.
the correct value to use would be
There is an assumption here that your first collection is the folders in
Once a month, for each folder listed, Pine will offer to move the contents of the folder to a new folder of the same name but with the previous month's date appended. Pine will then look for any such date-appended folder names created for a previous month, and offer each one it finds for deletion.
If you decline the first offer, no mail is moved and no new folder is created.
The new folders will be created in your default folder collection.
As a special case, if exactly one line of quoted text would be hidden, the entire quote will be shown instead. So for the above example, quoted text which is exactly six lines long will will be shown in its entirety. (In other words, instead of hiding a single line and adding a line that announces that one line was hidden, the line is just shown.)
If the sender of a message has carefully chosen the quotes that he or she includes, hiding those quotes may change the meaning of the message. For that reason, Pine requires that when you want to set the value of this variable to something less than four lines, you actually have to set it to the negative of that number. So if you want to set this option to "3", you actually have to set it to "-3". The only purpose of this is to get you to think about whether or not you really want to do this! If you want to delete all quoted text you set the value of this option to the special value "-10".
The legal values for this option are
| 0 | Default, don't hide anything |
| -1,-2,-3 | Suppress quote lines past 1, 2, or 3 lines |
| 4,5,6,... | Suppress if more than that many lines |
| -10 | Suppress all quoted lines |
If you set this option to a non-default value you may sometimes wish to view the quoted text that is not shown. When this is the case, the HdrMode (Header Mode) command may be used to show the hidden text. Typing the "H" command once will show the hidden text. Typing a second "H" will also turn on Full Header mode. The presence or absence of the HdrMode command is determined by the "Enable-Full-Header-Cmd" Feature-List option in your Pine configuration, so you will want to be sure to turn that on if you use quote suppression.
For the purposes of this option, a quote is a line that begins with the character ">".
Quotes are only suppressed when displaying a message on the screen. The entire quote will be left intact when printing or forwarding or something similar.
No matter what the value, the validity check is always done when the address book is about to be changed by the user. The check can be initiated manually by typing ^L (Ctrl-L) while in the address book maintenance screen for the remote address book.
By default, this setting will only work on messages that are flowed, which is the default way of sending messages for many mail clients including versions of Pine after 4.60. Enable the feature Quote-Replace-Nonflowed to also have quote-replacement performed on non-flowed messages.
Setting this option will replace ">" and "> " with the new setting. This string may include trailing spaces. To preserve those spaces enclose the full string in double quotes.
No padding to separate the text of the message from the quote string is added. This means that if you do not add trailing spaces to the value of this variable, text will be displayed right next to the quote string, which may be undesirable. This can be avoided by adding a new string separated by a space from your selection of quote string replacement. This last string will be used for padding. For example, setting this variable to ">" " " has the effect of setting ">" as the quote-replace-string, with the text padded by a space from the last quote string to make it more readable.
One possible setting for this variable could be " " (four spaces wrapped in quotes), which would have the effect of indenting each level of quoting four spaces and removing the ">"'s. Different levels of quoting could be made more discernible by setting colors for quoted text.
Replying to or forwarding the viewed message will preserve the original formatting of the message, so quote-replacement will not be performed on messages that are being composed.
This option specifies a different value for that string. If you wish to use a string which begins or ends with a space, enclose the string in double quotes.
Besides simple text, the prepended string can be based on the message being replied to. The following tokens are substituted for the message's corresponding value:
where the day of the week is only included if it is available in the original message. You may replace this default with text of your own. The text may contain tokens which are replaced with text which depends on the message you are replying to. For example, the default is equivalent to:
The list of available tokens is here.
For the adventurous, there is a way to conditionally include text based on whether or not a token would result in specific replacement text. For example, you could include some text based on whether or not the _NEWS_ token would result in any newsgroups if it was used. It's explained in detail here.
If your Reply-Leadin turns out to be longer than 80 characters when replying to a particular message, it is shortened.
In the very unlikely event that you want to include a literal token in the introduction line you must precede it with a backslash character. For example,
would produce something like
It is not possible to have a literal backslash followed by an expanded token.
imap).
/usr/ucb/rsh.
If this rule is set to last-folder-used, Pine offers to Save to the folder you last successfully Saved a message to (this session). The first time you Save a message in a session, Pine offers to Save the message to the default folder.
Choosing any of the by- options causes Pine to attempt to get the chosen option's value for the message being Saved (or for the first message being Saved if using an aggregate Save). For example, if by-from is chosen, Pine attempts to get the value of who the message came from (i.e. the from address). Pine then attempts to Save the message to a folder matching that value. If by-from is chosen and no value is obtained, Pine uses by-sender. The opposite is also true. If by-recipient was chosen and the message was posted to a newsgroup, Pine will use the newsgroup name. If by-replyto is chosen and no value is obtained, Pine uses by-from.
If any of the "by-realname" options are chosen, Pine will attempt to use the personal name part of the address instead of the mailbox part. If any of the "by-nick" options are chosen, the address is looked up in your address book and if found, the nickname for that entry is used. Only simple address book entries are checked, not distribution lists. Similarly, if any of the "by-fcc" options are chosen, the fcc from the corresponding address book entry is used. If by-realname, or the by-nick or by-fcc lookups result in no value, then if the chosen option ends with the "then-from", "then-sender", "then-replyto", or "then-recip" suffix, Pine reverts to the same behavior as "by-from", "by-sender", "by-replyto", or "by-recip" depending on which option was specified. If the chosen option doesn't end with one of the "then-" suffixes, then Pine reverts to the default folder when no match is found in the address book.
Here is an example to make some of the options clearer. If the message is From
and this rule is set to "by-from", then the default folder offered in the save dialog would be "flint".
If this rule is set to "by-realname-of-from" then the default would be "Fred Flintstone".
If this rule is set to "by-nick-of-from" then Pine will search for the address "flint@bedrock.org" in your address book. If an entry is found and it has a nickname associated with it, that nickname will be offered as the default folder. If not, the default saved message folder will be offered as the default.
If this rule is set to "by-fcc-of-from" then Pine will search for the address "flint@bedrock.org" in your address book. If an entry is found and it has an Fcc associated with it, that Fcc will be offered as the default folder. If not, the default saved message folder will be offered as the default.
If this rule is set to "by-nick-of-from-then-from" then Pine will search for the address "flint@bedrock.org" in your address book. If an entry is found and it has a nickname associated with it, that nickname will be offered as the default folder. If it is not found (or has no nickname) then the default offered will be the same as it would be for the "by-from" rule. That is, it would be "flint"
This option allows you to tell Pine the number of lines from the top and bottom screen edge that line-by-line scrolling should occur. For example, setting this value to one (1) will cause Pine to scroll the display when you move to select an item on the display's top or bottom edge (instead of moving when you move off the edge of the screen).
By default, this variable is zero (0), indicating that scrolling happens when you move up or down to select an item immediately off the display's top or bottom edge.
Sending filters do not work with PC-Pine and sending filters are not used if the feature send-without-confirm is set.
Command Modifying Tokens:
This defaults to
~/.signature on UNIX and <PINERC
directory>\PINE.SIG on a PC.
To create or edit your signature file choose Setup from the Main Menu and then select S for Signature (Main/Setup/Signature). This puts you into the Signature Editor where you can enter a few lines of text containing your identity and affiliation.
If the filename is followed by a vertical bar (|) then instead of reading the contents of the file the file is assumed to be a program which will produce the text to be used on its standard output. The program can't have any arguments and doesn't receive any input from Pine, but the rest of the processing works as if the contents came from a file.
Instead of storing the data in a local file, the signature data may be stored remotely in an IMAP folder. In order to do this, you must use a remote name for the file. A remote signature-file name might look like:
or, if you have an SSL-capable version of Pine, you might try
The syntax used here is the same as the syntax used for remote configuration files from the command line. Note that you may not access an existing signature file remotely, you have to create a new folder which contains the signature data. If the name you use here for the signature file is a remote name, then when you edit the file from the Setup/Signature command the data will be stored remotely in the folder. You aren't required to do anything special to create the folder, it gets created automatically if you use a remote name.
Besides regular text, the signature file may also contain (or a signature program may produce) tokens which are replaced with text which usually depends on the message you are replying to or forwarding. For example, if the signature file contains the token
anywhere in the text, then that token is replaced by the date the message you are replying to or forwarding was sent. If it contains
that is replaced with the current date. The first is an example of a token which depends on the message you are replying to (or forwarding) and the second is an example which doesn't depend on anything other than the current date. You have to be a little careful with this facility since tokens which depend on the message you are replying to or forwarding will be replaced by nothing in the case where you are composing a new message from scratch. The use of roles may help you in this respect. It allows you to use different signature files in different cases.
The list of tokens available for use in the signature file is here.
Instead of, or along with the use of roles to give you different signature files in different situations, there is also a way to conditionally include text based on whether or not a token would result in specific replacement text. For example, you could include some text based on whether or not the _NEWS_ token would result in any newsgroups if it was used. This is explained in detail here. This isn't for the faint of heart.
In the very unlikely event that you want to include a literal token in the signature you must precede it with a backslash character. For example,
would produce something like
It is not possible to have a literal backslash followed by an expanded token.
Your SMTP server may offer SMTP AUTH authentication. It may even require it. If your SMTP server offers SMTP AUTH authentication you may specify a "user" name parameter to cause Pine to attempt to authenticate. This parameter requires an associated value, the username identifier with which to establish the server connection. An example might be:
If AUTH authentication is offered by the server, this will cause Pine to attempt to use it. If AUTH authentication is not offered by the server, this will cause Pine to fail sending with an error similar to:
Another type of authentication that is used by some ISPs is called "POP before SMTP" or "IMAP before SMTP", which means that you have to authenticate yourself to the POP or IMAP server by opening a mailbox before you can send mail. To do this, you usually only have to open your INBOX.
You may tell Pine to use the Message Submission port (587) instead of the SMTP port (25) by including the "submit" parameter in this option. At this time "/submit" is simply equivalent to specifying port 587, though it may imply more than that at some point in the future. Some ISPs are blocking port 25 in order to reduce the amount of spam being sent to their users. You may find that the submit option allows you to get around such a block.
To specify any non-standard port number on the SMTP server you may follow the hostname with a colon followed by the portnumber.
Normally, when a connection is made to the Smtp-Server Pine will attempt to negotiate a secure (encrypted) session using Transport Layer Security (TLS). If that fails then a non-encrypted connection will be attempted instead. You may specify that a TLS connection is required if you wish. If you append "/tls" to the name then the connection will fail instead of falling back to a non-secure connection.
See the SMTP Servers section or the Server Name Syntax section for some more details.
For Unix Pine the program ispell works well as an
alternate spell checker.
If your Unix system has ispell it is probably reasonable to make
it the default speller by configuring it as the default in the
system configuration file, /usr/local/lib/pine.conf.
If this option is not set, then the system's spell command is used. The spell command does not work the same as the alternate speller. It produces a list of misspelled words on its standard output, instead, and doesn't take a tempfile as an argument. Don't set this speller option to the standard Unix spell command. That won't work. If you want to use the standard Unix spell command, set the speller option to nothing.
imap).
/usr/bin/ssh.