НАЗВА¶

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

ОПИС¶

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

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

Кожен окремий пункт mailcap складається з специфікації content-type, команди для виконання і (можливо) набору додаткових параметрів-«прапорців». Наприклад, дуже простий пункт файла mailcap (який описує насправді вбудовану стандартну функцію metamail) може виглядати подібно до:

 text/plain; cat %s

 text/plain; cat %s; copiousoutput

Поле «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>