Content-type: text/html Manpage of MAILCAP

MAILCAP

Section: Devices and Network Interfaces (4)
Updated: Release 2
Index Return to Main Contents
 

НАЗВА

mailcap - файл опису операц╕й для metamail  

ОПИС

Файл mailcap чита╓ться програмою metamail для того, щоб визначити як показувати не текстов╕ файли на локальному хост╕.

Синтаксис файла mailcap досить простий, як м╕н╕мум пор╕вняно з файлами termcap. Будь-який рядок, що почина╓ться з "#" - коментар. Пуст╕ рядки ╕гноруються. В ╕ншому випадку, кожен рядок визнача╓ один пункт mailcap для одного типу даних (content-type). Довг╕ пункти можна продовжувати на наступний рядок за допомогою зворотно╖ косо╖, \.

Кожен окремий пункт mailcap склада╓ться з специф╕кац╕╖ content-type, команди для виконання ╕ (можливо) набору додатковий параметр╕в-"прапорц╕в". Наприклад, дуже простий пункт файла mailcap (який опису╓ насправд╕ вбудовану стандартну функц╕ю metamail) може виглядати под╕бно до:

text/plain; cat %s

Додатков╕ прапорц╕ можна використовувати для вказання додатково╖ ╕нформац╕╖ про команду обробки поштового пов╕домлення. Наприклад:

text/plain; cat %s; copiousoutput

може використовуватись для ╕ндикац╕╖, що команда 'cat' може видати багато ╕нформац╕╖ на екран, що вимага╓ або екрана з можливостями прокрутки, постор╕нкового показу чи якогось ╕ншого механ╕зму.

Поле "type" (в наведеному вище приклад╕ - text/plain), це просто будь-який дозволений тип, визначений стандартом RFC 822. Насправд╕, це може бути майже дов╕льний рядок. Це рядок, який буде пор╕внюватись з заголовком "Content-type" (або з╕ значенням наданим ключем -c) для того, щоб вир╕шити, чи цей пункт mailcap в╕дпов╕да╓ даному листу. Додатково поле типу може мати п╕д-тип (наприклад: "text/ISO-8859-1") або шаблон для вибору вс╕х можливих п╕д-тип╕в (наприклад: "image/*").

Поле "command" - це будь-яка команда UNIX'а (у приклад╕ вище, це - "cat %s"), ╕ використову╓ться для того, щоб ╕нтерпретувати даний тип листа. Ця команда буде передана командн╕й оболонц╕ через механ╕зм system(3). Крапки з комою та зворотн╕ кос╕ в т╕л╕ команди будуть цитуватись за допомогою зворотн╕х косих. Якщо в т╕л╕ команди знаходиться "%s", ц╕ два символи зам╕нюються на назву файла, в якому записане т╕ло листа. Якщо в т╕л╕ команди вказан╕ символи "%t", вони будуть зам╕нен╕ на поле content-type разом з будь-яким п╕д-типом включно (якщо такий вказано). Тобто, якщо content-type вказано як "image/pbm; opt1=something-else", то зам╕сть "%t" буде п╕дставлено "image/pbm". Якщо в т╕л╕ команди вказано "%{", за яким ╕де назва параметру ╕ закриваюча дужка "}" п╕сля цього, ц╕ символи будуть зам╕нен╕ на значення вказаного параметра, якщо такий ма╓ться, з заголовку Content-type. Тобто, в попередньому приклад╕ зам╕сть "%{opt1}" буде надруковано "something-else". ╤, нарешт╕, якщо в команд╕ вказано "\%", ц╕ два символи буде зам╕нено на один символ %. (Насправд╕, зворотня коса може використовуватись щоб цитувати будь-який символ, в тому числ╕ ╕ саму себе).

Якщо в команд╕ не присутня комб╕нац╕я "%s", тод╕ зам╕сть того, щоб записувати т╕ло листа в тимчасовий файл, metamail передасть т╕ло команди на стандартний вв╕д. Це зручно, якщо потр╕бно зекономити прост╕р в /tmp, але може бути проблематичним з деякими програмами, що ор╕╓нтуються на в╕конний ╕нтерфейс при робот╕ з деякими в╕конними менеджерами, такими як, наприклад, MGR.

В команд╕ можуть бути присутн╕ми два спец╕альних коди для об'╓кт╕в, як╕ ╓ частинами лист╕в, як╕ складаються з к╕лькох розд╕л╕в (multipart type -- прим. перекладача). Це так╕ коди як "%n" ╕ "%T". Зам╕сть "%n" п╕дставля╓ться номер розд╕лу. Зам╕сть "%T" буде п╕дставлена посл╕довн╕сть параметр╕в, по два на кожен окремий розд╕л, як╕ задають content-type ╕ назву тимчасового файла, де буде записано декодований розд╕л. Додатково, для кожного файла, який створю╓ться за допомогою %F, буде також створено ще один файл з такою ж назвою, як ╕ перший ╕ з долученим до назви "H", в якому буде записано ╕нформац╕ю про заголовки цього п╕дрозд╕лу. Для б╕льшост╕ програм обробки лист╕в з багатьма частинами ця ╕нформац╕я не буде потр╕бна, але вона присутня, якщо раптом вона знадобиться.

Поле "notes=xxx" не ╕нтерпрету╓ться. Це - рядок який використову╓ться для того, щоб вказати ╕м'я особи, яка встановила даний пункт в файл mailcap. (Рядок "xxx" можна зам╕нити на будь-який текстовий рядок).

Поле "test=xxx" - це команда, яка викону╓ться для того, щоб визначити, чи правило з файла mailcap насправд╕ викону╓ться. Тобто, якщо content-type листа в╕дпов╕да╓ content-type файла mailcap, ╕ присутн╕й параметр "test=", тод╕ перш, н╕ж показувати листа, повинна буде усп╕шно виконана команда вказана в пол╕ "test". Команда може бути будь-якою командою UNIX з використанням такого ж синтаксису ╕ правил щодо %, як це описано вище. Виконання команди вважа╓ться усп╕шним, якщо вона зак╕нчилась ╕ кодом 0 ╕ неусп╕шним в ус╕х ╕нших випадках.

Поле "print=xxx" вказу╓ команду, яка використову╓ться для друку листа, зам╕сть того, щоб показувати його ╕нтерактивно. Це часто ╓ результатом виконання команди metamail з параметром "-h".

Поле "textualnewlines" може використовуватись для тако╖ невидимо╖ на перший погляд ситуац╕╖, коли стандартн╕ правила поводження з символами к╕нця рядка в metamail для закодованих в формат base64 даних незадов╕льн╕. Стандартно, metamail переводить CRLF в локальний для дано╖ системи символ к╕нця рядка в розкодованих з base64 даних, якщо content-type вказаний як "text" (будь-якого п╕д-типу), але не робить цього в ╕нших випадках. Встановлення поля "textualnewlines=1" примусово встановлю╓ транслювання символу к╕нця рядка для вказаного content-type, в той час як встановлення "textualnewlines=0" гаранту╓, що така трансляц╕я не буде виконуватись нав╕ть для текстових content-type.

Поле "compose" може використовуватись для вказання програми, яка використову╓ться для редагування нового т╕ла листа чи частини т╕ла листа в даному формат╕. ╥╖ використання нац╕лене на п╕дтримку таких агент╕в (програмних засоб╕в) для складання поштових пов╕домлень, як╕ п╕дтримують складання лист╕в р╕зних тип╕в за допомогою зовн╕шн╕х компонент для написання таких лист╕в (частин лист╕в). Так само, як ╕ з командою перегляду, команда редагування буде виконана п╕сля зам╕ни певних контрольних посл╕довностей символ╕в, як╕ починаються з "%". Наприклад, %s зам╕ню╓ться назвою файла, куди будуть записуватись створен╕ дан╕ вказаною програмою редагування, таким чином дозволяючи т╕й програм╕, яка виклика╓ ╖╖ (тобто metamail) вказати програм╕ складання м╕сце для запису даних. Якщо в командному рядку нема╓ комб╕нац╕╖ символ╕в %s, програма редагування вважа╓, що дан╕ повинн╕ писатись на стандартний вив╕д. Результатом роботи програми редагування можуть бути дан╕, як╕ не годяться для прямо╖ пересилки каналами електронно╖ пошти, тобто, до таких даних все ще потр╕бно буде застосувати Content-Transfer-Encoding.

Поле "composetyped" под╕бне до "compose", але призначене для програмам, яким потр╕бно вказувати заголовок Content-type щоб застосувати його до створених даних. Поле "compose" прост╕ше, ╕ йому повинна надаватись перевага для вживання з ╕снуючими (не ор╕╓нтованими специф╕чно на використання в електронн╕й пошт╕) програмами для створення даних в заданому формат╕. Поле "composetyped" потр╕бне для тих випадк╕в, коли ╕нформац╕я про Content-type повинна м╕стити зовн╕шн╕ параметри ╕ в цьому випадку програма редагування даних повинна знати достатньо про поштов╕ формати для створення вих╕дних даних, що м╕стять ╕нформац╕ю про тип поштового пов╕домлення ╕ для застосування в╕дпов╕дних Content-Transfer-Encoding. Концептуально, "compose" вказу╓ т╕льки програму, яка просто виводить вказан╕ дан╕ в "сирому" формат╕, в той час як "composetyped" вказу╓ програму, яка виводить дан╕ у вигляд╕ об'╓кту MIME з ус╕ма необх╕дними заголовками типу Content-* розставленими по м╕сцях.

needsterminal
Якщо цей прапорець встановлено, вказаному ╕нтерпретатору потр╕бна вза╓мод╕я з користувачем на терм╕нал╕. В деяких робочих середовищах (наприклад, в ор╕╓нтованих на роботу з в╕кнами поштових програмах в X11) для цього буде потр╕бно створення нового в╕кна емулятора терм╕нала, хоча в б╕льшост╕ робочих середовищ, цього не потр╕бно. Якщо пункт mailcap вказу╓ "needsterminal" ╕ metamail працю╓ не на терм╕нал╕ (це визнача╓ться за допомогою isatty(3), опц╕╖ -x ╕ зм╕нно╖ середовища MM_NOTTTY), metamail буде намагатися виконати команду в новоствореному в╕кн╕ емулятора терм╕нала. На даний час metamail зна╓ як створювати нов╕ в╕кна в середовищах X11, SunTools та WM.

copiousoutput
Цей прапорець повинен використовуватись коли ╕нтерпретатор може видати на стандартний вив╕д б╕льше, н╕ж к╕лька рядк╕в ╕ не вза╓мод╕╓ з користувачем безпосередньо. Якщо пункт mailcap вказу╓ copiousoutput, ╕ постор╕нковий вив╕д запрошений командою "-p", то вив╕д команди буде пропускатися через канал програму постор╕нкового виводи (стандартно "more", але це може бути зм╕нено встановленням зм╕нно╖ середовища METAMAIL_PAGER).

 

ВБУДОВАНА П╤ДТРИМКА ДЛЯ CONTENT-TYPE

Програма metamail ма╓ вбудовану п╕дтримку для к╕лькох ключових тип╕в content-type. Програма п╕дтриму╓ так╕ типи: text, multipart ╕ multipart/alternative ╕ message/rfc822. Ця п╕дтримка неповна для багатьох п╕д-тип╕в. Наприклад, вона загалом п╕дтриму╓ т╕льки US-ASCII текст. Ця стандартна п╕дтримка може бути ЗМ╤НЕНА (OVERRIDDEN в ори╜╕нал╕, прим. перекладача) пунктом в будь-якому з файл╕в mailcap, як╕ доступн╕ на маршрутах пошуку користувача. Програма metamail ма╓ також зародкову вбудовану п╕дтримку для тип╕в, як╕ зовс╕м не розп╕знаються. Тобто, для таких, як╕ не мають свого власного пункту в файл╕ mailcap чи для яких не ╕сну╓ вбудованого обробника. Для таких тип╕в, не розп╕знаних metamail'ом, програма запису╓ файл з "чистою" коп╕╓ю даних. Тобто, даними, де вс╕ поштов╕ заголовки прибран╕ ╕ де будь-як╕ 7-б╕тн╕ перекодовування для транспортування даних декодован╕.

 

ФАЙЛИ

$HOME/.mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap -- стандартний маршрут пошуку файл╕в типу mailcap.  

ДИВ. ТАКОЖ

metamail(1)  

COPYRIGHT

Copyright (c) 1991 Bell Communications Research, Inc. (Bellcore)

Нада╓ться дозв╕л на використання, дублювання, внесення зм╕н ╕ поширення цього матер╕алу для будь-якого призначення ╕ без вимоги будь-яко╖ плати за це, за умови, що подане вище пов╕домлення про COPYRIGHT ╕ цей дозв╕л з'явля╓ться в ус╕х коп╕ях, ╕ що назва Bellcore не буде використовуватись в рекламних чи под╕бних ц╕лях без специф╕чно вказаного, попереднього письмового дозволу авторизованого представника ф╕рми Bellcore. BELLCORE НЕ НЕСЕ В╤ДПОВ╤ДАЛЬНОСТ╤ ЩОДО ДОСТОВ╤РНОСТ╤ ЧИ В╤ДПОВ╤ДНОСТ╤ ЦЬОГО МАТЕР╤АЛУ БУДЬ-ЯК╤Й МЕТ╤. В╤Н НАДА╢ТЬСЯ НА УМОВАХ "ЯК ╢", БЕЗ ЖОДНИХ ЯВНО ВИРАЖЕНИХ ЧИ УЯВНИХ ГАРАНТ╤Й.  

АВТОР

Nathaniel S. Borenstein  

ПЕРЕКЛАД


Дмитро Ковальов, <kov@tokyo.emai.ne.jp>


 

Index

НАЗВА
ОПИС
ВБУДОВАНА П╤ДТРИМКА ДЛЯ CONTENT-TYPE
ФАЙЛИ
ДИВ. ТАКОЖ
COPYRIGHT
АВТОР
ПЕРЕКЛАД

This document was created by man2html, using the manual pages.
Time: 13:19:39 GMT, May 15, 2003