Struct mailcap::Entry

source · [−]

pub struct Entry { /* private fields */ }

Expand description

Parsed mailcap line. Each mailcap entry consists of a number of fields, separated by semi-colons. The first two fields are required, and must occur in the specified order. The remaining fields are optional, and may appear in any order.

Implementations

source

impl Entry

source

pub fn mime(&self) -> &String

The mime_type, which indicates the type of data this mailcap entry describes how to handle. It is to be matched against the type/subtype specification in the “Content-Type” header field of an Internet mail message. If the subtype is specified as “*”, it is intended to match all subtypes of the named mime_type.

source

pub fn viewer(&self, filename: &str) -> String

The second field, viewer, is a specification of how the message or body part can be viewed at the local site. Although the syntax of this field is fully specified, the semantics of program execution are necessarily somewhat operating system dependent. UNIX semantics are given in Appendix A of RFC 1524.

source

pub fn compose(&self) -> &Option<String>

The compose field may be used to specify a program that can be used to compose a new body or body part in the given format. Its intended use is to support mail composing agents that support the composition of multiple types of mail using external composing agents. As with viewer, the semantics of program execution are operating system dependent, with UNIX semantics specified in Appendix A of RFC 1524. The result of the composing program may be data that is not yet suitable for mail transport – that is, a Content-Transfer-Encoding may need to be applied to the data.

source

pub fn compose_typed(&self) -> &Option<String>

The compose_typed field is similar to the compose field, but is to be used when the composing program needs to specify the Content-type header field to be applied to the composed data. The compose field is simpler, and is preferred for use with existing (non-mail-oriented) programs for composing data in a given format. The compose_typed field is necessary when the Content-type information must include auxilliary parameters, and the composition program must then know enough about mail formats to produce output that includes the mail type information.

source

pub fn edit(&self) -> &Option<String>

The edit field may be used to specify a program that can be used to edit a body or body part in the given format. In many cases, it may be identical in content to the compose field, and shares the operating-system dependent semantics for program execution.

source

pub fn print(&self) -> &Option<String>

The print field may be used to specify a program that can be used to print a message or body part in the given format. As with viewer, the semantics of program execution are operating system dependent, with UNIX semantics specified in Appendix A of RFC 1524.

source

pub fn test(&self) -> &Option<String>

The test field may be used to test some external condition (e.g., the machine architecture, or the window system in use) to determine whether or not the mailcap line applies. It specifies a program to be run to test some condition. The semantics of execution and of the value returned by the test program are operating system dependent, with UNIX semantics specified in Appendix A of RFC 1524. If the test fails, a subsequent mailcap entry should be sought. Multiple test fields are not permitted – since a test can call a program, it can already be arbitrarily complex.

source

pub fn description(&self) -> &Option<String>

The description field simply provides a textual description, optionally quoted, that describes the type of data, to be used optionally by mail readers that wish to describe the data before offering to display it.

source

pub fn name_template(&self) -> &Option<String>

The name_template field gives a file name format, in which %s will be replaced by a short unique string to give the name of the temporary file to be passed to the viewing command. This is only expected to be relevant in environments where filename extensions are meaningful, e.g., one coulld specify that a GIF file being passed to a gif viewer should have a name eding in “.gif” by using “nametemplate=%s.gif”.

source

pub fn needs_terminal(&self) -> &bool

The needs_terminal field indicates that the viewer must be run on an interactive terminal. This is needed to inform window-oriented user agents that an interactive terminal is needed. (The decision is not left exclusively to viewer because in some circumstances it may not be possible for such programs to tell whether or not they are on interactive terminals). The needs_terminal command should be assumed to apply to the compose and edit commands, too, if they exist. Note that this is NOT a test – it is a requirement for the environment in which the program will be executed, and should typically cause the creation of a terminal window when not executed on either a real terminal or a terminal window.

source

pub fn copious_output(&self) -> &bool

The copious_output field indicates that the output from viewer will be an extended stream of output, and is to be interpreted as advice to the UA (User Agent mail-reading program) that the output should be either paged or made scrollable. Note that it is probably a mistake if needs_terminal and copious_output are both specified.

source

pub fn textual_new_lines(&self) -> &bool

The textual_new_lines field, if set to any non-zero value, indicates that this type of data is line-oriented and that, if encoded in base64, all newlines should be converted to canonical form (CRLF) before encoding, and will be in that form after decoding. In general, this field is needed only if there is line-oriented data of some type other than text/* or non-line-oriented data that is a subtype of text.