Введение в POSIX'ивизм

         

О шеллах


Жизнь дает человеку три радости -

дружбу, любовь и работу...

Братья Стругацкие

Перефразируя классиков советской фантастики, можно сказать, что жизнь дает POSIX'ивисту три радости: дружественный шелл, любимый текстовый редактор и много, очень много приложений для работы. Без любой из первых двух радостей прожить можно. Но это значит, что радостей будет одной меньше. А ведь их всего три. Так что эту главу я посвящаю первой из радостей - шеллам. Тем более, что это еще и первое приложение, с которым сталкивается пользователь после авторизации в системе.



Какие бывают шеллы


Большая часть командных оболочек делится, на основе синтаксиса интерпретируемого ими языка, на две группы - sh- и csh-совместимые (о специфических шеллах, базирующихся, например, на диалекте LISP, я говорить не буду за их незнанием). На самом деле различия между ними синтаксисом команд не исчерпываются, а лежат глубже - в подходе к обработке командных конструкций, к чему мы еще вернемся.

Оболочки, относимые к sh-совместимым, происходят от первой командной оболочки первых Unix-систем, которую так и называют - shell или Bourne Shell (то есть шелл Борна). В ней были заложены многие возможности для интерпретации команд и их конструкций, то есть составления системных и пользовательских сценариев. Однако по своим интерактивным возможностям она оставляла желать лучшего, и потому на базе ее была создана оболочка Корна (Korne Shell).

Шелл Корна сохранил совместимость с борновским шеллом на уровне синтаксиса, однако привнес в него как дополнительные возможности интерпретации команд, так и приемы, направленные на удобство интерактивной работы. И потому именно он лег в основу стандарта POSIX, которому должны удовлетворять командные оболочки совместимых с ним систем.

Следует заметить, что соответствие этому стандарту - один из критериев отнесения некоей ОС к семейству Unix или Unix-подобных. В частности, именно такой стандартизированный шелл должен вызываться при исполнении общесистемных сценариев инициализации любой POSIX-системы. Сам же по себе POSIX shell - некая мифическая абстракция, ближе к которой подходят /bin/sh - умолчальная пользовательская оболочка из FreeBSD, и ash, принятая в качестве стандартной в NetBSD (а также широко используемая во всяких мини-дистрибутивах Linux).

Шеллы и Борна, и Корна не были свободно распространяемыми программами в терминах GPL-совместимых лицензий. Поэтому ни тот, ни другой не могли использоваться в таких ОС, как *BSD или Linux, хотя свободная реализация оболочки Корна (pdksh) и была создана. Однако, как и ее прототип, шелл Корна, она, несколько развившись относительно первозданного Bourne shell, обладала интерактивными достижениями, уже далекими далекими от идеала.
Столь же слабы они были и в ash. И потому наиболее широкое распространение из всего sh-совместимого семейства получила оболочка bash (что расшифровывается как "еще одна оболочка Борна", "заново рожденный шелл" и тому подобным образом), разработанная в рамках проекта GNU.

Популярность bash в немалой степени была обусловлена его интерактивными возможностями - он аккумулировал все достижения интерактивной мысли sh- и csh-совместимых оболочек, прибавив к ним немало собственных. И умудрившись при этом сохранить базовую совместимость с POSIX shell. Конечно, многие его собственные особенности (так называемые "bash'измы") выходили за рамки этого стандарта. Однако для соответствия оному был предусмотрен режим совместимости - то есть bash был способен эмулировать стандартный POSIX shell.

Однако главным для популярности bash было то, что эта оболочка оказалась тесно интегрирована с операционной системой Linux: именно bash волею судеб стал одной из первых программ, которые Линус запустил поверх своего новосозданного ядра. И потому идеи bash-скриптинга пронизали Linux до самых его оснований. Ну а для совместимости использовался тот самый режим эмуляции: в Linux файл, запускающий POSIX shell (по стандарту он должен именоваться /bin/sh), являет собой жесткую или символическую ссылку на реальный /bin/bash. Последний же, будучи вызванным таким образом, полностью воспроизводит функционально стандартный POSIX shell (разумеется, путем утраты своих продвинутых функций).

Клан csh-совместимых оболочек развивался параллельно сынам и пасынкам Борна. Собственно оболочка csh (или C-shell) была создана в Университете Беркли на начальных этапах реализации проекта BSD Unix. Первым ее разработчиком был Билл Джой - автор также и культового текстового редактора юниксоидов, vi, а в последующем один из основателей фирмы Sun.

Оболочка C-shell получила дополнительные интерактивные возможности, во многом превосходящие таковые не только у современного ей шелла Борна, но и появившегося позднее шелла Корна.




Главное же - языку, ею интерпретируемому, были приданы черты синтаксического сходства с языком Си (откуда, собственно, и название - C-Shell, хотя не следует думать, что на всамделишний Си ее интерпретируемый язык похож). В результате оболочка csh оказалась весьма эффективной как для интерактивной работы, так и при создании сценариев. Только вот сценарии эти не были совместимы со скриптами POSIX shell, обретшего уже силу стандарта. То есть, при всей эффективности пользовательского шелл-программирования, для создания общесистемных сценариев она оказалась практически непригодной.

В отличие от большинства прочих достижений берклианской мысли, оболочка csh, по не вполне ясным для меня причинам, не обрела статуса свободной программы. Поэтому она не могла использоваться даже в своих родных пенатах - в BSD-системах. Однако на замену ей была изобретена свободная оболочка tcsh - не просто функциональное воспроизведение, но и дальнейшее развитие оболочки csh. По интерактивным возможностям она, как минимум, не уступает bash и потому прочно утвердилась в стане свободных BSD-клонов как пользовательский шелл по умолчанию.

В частности, оболочка tcsh принята в качестве login shell для суперпользователя во FreeBSD. Правда, вызывается она в режиме совместимости с csh, однако /bin/csh - не более чем жесткая ссылка на /bin/tcsh.

Оболочка tcsh используется в качестве универсального "умолчального" пользовательского шелла также в OpenBSD и DragonFlyBSD. Однако характерно, что все общесистемные сценарии в обеих ОС написаны, тем не менее, в соответствие с требованиями POSIX Shell.


Кое что о csh и tcsh


Оболочки семейства C-Shell не избалованы вниманием русскоязычных авторов, почему я и решил удеить им особое внимание. Тем более, что tcsh объединяет преимущества синтаксиса csh и удобные средства настройки и интерактивной работы bash: многие из них были ассимилированы в zsh.

Командная оболочка csh пришла к нам из BSD-мира и традиционно пользуется популярностью среди пользователей этих систем. Правда, изначальный ее вариант (собственно csh) не принадлежит к числу свободно распространяемых программ. И потому в открытых BSD-клонах используется ее разновидность от Open Sources- оболочка tcsh. Которую, впрочем, никто не запрещает применять и в Linux'е.

Как уже говорилось, внешние различия между основными семействами командных оболочек лежат в первую очередь в области синтаксиса собственного их языка. В клонах Bourne Shell язык этот ни на что, насколько я понимаю, особенно не похож. В оболочке C-Shell и ее производных синтаксис встроенного языка, как и следует из названия, схож с таковым всамделишнего языка программирования Си.

Си-подобный синтаксис встроенного языка csh (и tcsh) обеспечивает существенно больший лаконизм сценариев, чем в скриптах shell-совместимых интерпретаторов. Правда, именно при создании сценариев использование оболочки csh может быть ограничено ее несовместимостью со стандартом POSIX.

Различия в синтаксисе между семействами sh и csh отражают различие их обращения с условными выражениями. В классических шеллах это - просто последовательности команд (подобные конвейерам), в которых выполнение каждой последующей определяется успешным или неуспешным завершением предыдущей. В csh же они представляют собой вычисляемые арифметические или логические выражения.

Далее, важное с точки зрения пользователя различие - обращение с путями к исполняемым файлам. Клоны шелла Борна при вводе команды перечитывают состав каталогов, включенных в качестве значений переменной PATH. В клонах же csh эти значения, считываясь один раз при старте, далее хранятся в чем-то типа собственного буфера, именуемого хэш-таблицей.
В результате чего достигается выигрыш в быстродействии исполнения внешних команд. Оборотная сторона - при добавлении к одному из каталогов переменной PATH нового файла (типичный случай - при установке новой программы) оболочка csh его просто не увидит; то есть для вызова такой новой программы в текущем сеансе придется указывать полный путь к ее исполнимому файлу. Или - перестроить хэш-таблицу, для чего предназначена специальная встроенная команда rehash.

Наконец, в csh по иному определяются переменные. Если во всех POSIX-шеллах для этого достаточно задать имя и значение, то здесь этой цели служит специальная встроенная команда set, например:

set EDITOR joe

определит редактор по умолчанию. Впрочем, таким образом будет задана только переменная оболочки - средств экспорта их в среду в csh не имеется. Для задания переменных среды существует отдельная встроенная команда setenv:

setenv EDITOR joe

Каждая из этих команда, данная без аргументов, выведет список определенных переменных оболочки и окружения соответственно. А для вывода значений абсолютно всех переменных есть специальная встроенная команда - printenv.

Командная оболочка tcsh - это вариант C-Shell с мощными возможностями дополнения имен файлов и редактирования командной строки; нельзя не отметить, что в оригинальной csh они развиты существенно слабее, чем, скажем, в bash. Тем не менее, tcsh полностью совместима со своим прототипом с точки зрения синтаксиса.

Как и все другие оболочки, tcsh объединяет в себе интерактивный командный процессор и интерпретатор собственного языка сценариев, превращающий ее в простую в обращении, но весьма мощную среду программирования.

Одна из основных функций любой командной среды - исполнение команд, внешних (то есть независимых программ) и встроенных. Встроенные и внешние команды могут иногда дублировать функции друг друга, но при прочих равных условиях применение первых - предпочтительней, они выполняются быстрее. И набор встроенных команд - это то, что, помимо всего прочего, отличает командные среды друг от друга и определяет их функциональность.



Среда tcsh содержит достаточно большое (говорят, больше 50, я считать поленился) количество встроенных команд. Полный их список можно получить с помощью команды builtins (к слову сказать, также встроенной), ответом на которую будет список вроде этого:

: @ alias alloc bg bindkey break breaksw builtins case cd chdir complete continue default dirs echo echotc else end endif endsw eval exec exit fg filetest foreach glob goto hashstat history hup if jobs kill limit log login logout ls-F nice nohup notify onintr popd printenv pushd rehash repeat sched set setenv secodec secodey shift source stop suspend switch telltc time umask unalias uncomplete unhash unlimit unset unsetenv wait where which while

Все эти команды могут использоваться как в интерактивном режиме, так и в составе сценариев (скриптов). Описание команд можно найти в экранной документации. На некоторых наиболее используемых из них я буду останавливаться по ходу дела.

Основные возможности, предоставляемые tcsh в интерактивном режиме, помимо собственно исполнения команд, включают:

редактирование командной строки;

дополнение слов (word completion) - как для путей, так и для команд;

хранение и воспроизведение истории команд;

управление текущими задачами (job control).

Редактор командной строки предоставляет средства навигации внутри нее, с возможностью изменения отдельных знаков и компонентов команд, их опций и аргументов.

Навигация по командной строке и ее редактирование осуществляется двумя различными способами. Первый - использование стандартных клавиш управления курсором, таких, как Left и Right, Home и End, для навигации, и клавиш Delete и Backspase - для редактирования. Достоинство его - в простоте, вернее, в привычности: в ряде случаев эти клавиши ведут себя так же, как и в программах для DOS/Windows. Однако - далеко не всегда: на многих типах терминалов хоть какая-то из этих клавиш (а то и все сразу) обнаруживают аномальные особенности поведения.

Этого недостатка лишен второй способ навигации и редактирования - с использованием специальных клавишных комбинаций.


Каковые на всех известных мне консолях ведут себя практически идентично. И к тому же предоставляют, по сравнению со стандартными клавишами, дополнительные возможности.

Управляющие комбинации (bindkeys) в большинстве случаев имеют вид Control+литера (то есть литерная клавиша нажимается при нажатой клавише Control) или Escape-литера (когда литерная клавиша нажимается непосредственно сразу клавиши Escape). Все они не чувствительны к регистру и, насколько мне удалось выяснить, также и к раскладке клавиатуры (то есть работают, вне зависимости от переключения, например, с латиницы на кириллицу и обратно).

Полный список управляющих комбинаций для tcsh может быть получен командой

$ binkdkey

Одни из них дублируют стандартные клавиши перемещения курсора, такие, как:

Control+A - перемещение курсора в начало строки;

Control+E - перемещение курсора в конец строки;

Control+F - перемещение курсора на один знак вперед;

Control+B - перемещение курсора на один знак назад;

Другие же управляющие комбинации дают возможность перемещаться на одно слово вперед или назад (Escape-F и Escape-B, соответственно), в предыдущую позицию курсора (Control+X-X), удалять целиком слово (Escape-D) или часть строки после курсора, перемещать знаки (transpose-chars, Control+T), изменять регистр знаков и многое другое. А поскольку под все эти операции задействованы только клавиши основой части клавиатуры, скорость их выполнения - непревзойденная (при наличии некоторого навыка, доведенного, желательно, до рефлекторного уровня).

Следующая неоценимая возможность tcsh - дополнение слов. Которое работает как для команд, так и для имен файлов и путей к ним. То есть при наборе первых знаков команды (или файла) соответствующее действие (например, нажатие клавиши табуляции) автоматически дополняет недостающие знаки. Если, конечно, набранных знаков хватает для однозначной идентификации. Если же не хватает - есть возможность просмотреть списков доступных вариантов и выбрать из них подходящий (эта функция именуется autolist).



Как обычно, дополнение слов выполняется двояким способом - или клавишей TAB, или управляющими комбинациями. Из них отметим Control+I - собственно дополнение слова, и Control+D - вызов списка вариантов для дополнения; в последнем случае курсор обязательно должен стоять после последнего введенного символа - иначе эта комбинация сработает на удаление знака под курсором.

Следует отметить, что вывод альтернатив для автодополнения в tcsh по умолчанию не предусмотрен, требуя специальных настроек в профильном файле (каких - скажу чуть позже).

История команд подразумевает, что некоторое количество ранее введенных команд сохраняется в специальном буфере, и может быть вызвано для просмотра, исполнения или редактирования.

Для этого можно использовать клавиши управления курсором - Up (назад) и Down (вперед), с помощью которых как бы "пролистываются" по одной все ранее введенные команды. Аналогичного результата можно добиться и управляющими комбинациями - Control+P и Control+N или Escape+P и Escape+N, каждая пара из которых является аналогом пары Up и Down, соответственно.

Кроме этого, историю эту можно просмотреть с помощью встроенной команды history, которая выдаст нумерованный список всех выводившихся ранее (в количестве, определенном в файле конфигурации среды) команд, например:

$ history 1 17:19 logout 2 17:57 history 3 17:57 pwd 4 17:57 ls 5 17:57 ls -laFG 6 17:57 history

Любая из них вызывается в командную строку с помощью конструкции

!#

где # - порядковый номер команды в списке. Как и во всех прочих развитых оболочках, команду из истории можно отредактировать и (или) запустить на исполнение.

Общесистемные файлы конфигурации tcsh - файлы типа /etc/csh.cshrc и /etc/csh.login (точные имена в разных системах BSD-семейства, в базовый комплект которых входит эта оболочка, моут быть разными, пример приведен для DragonFlyBSD). При необходимости их аналоги, ~/.cshrc и ~/.login, создаются в домашнем каталоге пользователя. В отличие sh-совместимых оболочек, файлы csrc-группы считываются (сначала - общесистемный, затем - "домашний") при запуске любого экземпляра tcsh.


Обращение же к файлу /etc/csh.login, а потом и к его "домашнему" аналогу - ~/.login, происходит только при запуске оболочки пользователя (login shell), хотя и после файлов cshrc-группы. Для csh порядок считывания dot-файлов определяется при компиляции и может быть изменен пересборкой оболочки.

Кроме того, в домашнем каталоге пользователя может обнаружиться еще два конфигурационных файла, считываемых последовательно после главных: истории команд ~/.history и ~/.cshdirs, в котором описываются стартовый каталог оболочки, если требуется сделать ее отличной от умолчального ~/ . При выходе из пользовательской оболочки выполняются действия, предписанные в файле /etc/csh.logout или ~/.logout.

Впрочем, в большинстве случаев пользователь вполне может обойтись единственным конфигом - ~/.cshrc (не считая ~/.history, который образуется и заполняется автоматически. Как пример, могу привести прокомментированное содержимое своего пользовательского dot-файла для tcsh.

# .cshrc - стартовый конфиг tcsh # считывается при каждом запуске

# Псевдонимы для команд управления файлами

alias h history 25 # Вывод последних 25 команд из файла истории

alias cp cp -iR # Рекурсивное копирование с запросом подтверждения перезаписи alias cpf cp -Rf # Рекурсивное копирование с принудительной перезаписью

alias rm rm -i # Удаление файлов с запросом подтверждения

alias rmf rm -Rf # Принудительное рекурсивное удаление файлов

alias mv mv -i alias mvf mv -f # Перемещение/переименование файлов # с запросом подтверждения и принудительно, # соответственно

# Псевдонимы команды ls

alias ls ls -FG # Колоризованный вывод с типизацией файлов

alias la ls -A # Вывод всех файлов, за исключением . и ..

alias ll ls -l # Вывод списка файлов в "длинном" формате

alias li ls -ial # Вывод всех файлов в длинном формате с указанием идентификаторов

# Прочие псевдонимы alias df df -h alias du du -h # Вывод с подбором единиц измерения

alias less less -M Вывод команды less в "more-подобном" виде

# Установка прав доступа для новообразованных файлов umask 022



# Основные переменные оболочки и окружения

set path = (/usr/bin /usr/local/bin /usr/local/sbin /usr/X11R6/bin) # Определение путей к исполняемым файлам

set autolist # Вывод списка альтернатив для автодополнения # по нажатию табулятора

set ignoreeof # Запрет завершения сеанса по комбинации Control+D

set correct = cmd # Автокоррекция команд

set histdup = erase # Очистка файла истории команд от дубликатов

set prompt = '%~->' # Установка вида приглашения

setenv EDITOR joe setenv PAGER less # Редактор и Pager по умолчанию

# Переменные для интерактивных экземпляров tcsh if ($?prompt) then # Установить следующие переменные, # если определена переменная prompt set history = 1000 set savehist = 1000 # Установить число строк # в истории команд текущего сеанса # и в файле истории, соответственно if ( $?tcsh ) then # Поведение клавиш (только для tcsh) bindkey "^W" backward-delete-word bindkey -k up history-search-backward bindkey -k down history-search-forward endif endif

Приведенным примером возможности настройки tcsh отнюдь не исчерпываются - за подробностями можно обратиться к man tcsh.


О шеллах вообще


Шелл (Shell), именуемый по-русски командной оболочкой, командным интерпретатором, командным процессором или иными, столь же неизящными словосочетаниями, - это первая программа, с которой сталкивается пользователь любой POSIX-совместимой ОС. И с ним же последним он расстается, выходя из системы. А все его действия во время работы - суть прямые или опосредованные команды, выполняемые в среде шелла. И даже если основная часть работы пользователя проходит в графическом режиме, в окружении интегрированных сред или оконных менеджеров, - окно терминала с приглашением командной строки быстро станет неотъемлемым атрибутом любого десктопа. Ибо, как я пытался показать в и ряде интермедий, именно команды оболочки - самый простой и эффективный путь к выполнению всех операций по , многих задач , да и просто запуска любых программ, что в консоли, что - в графическом режиме.

Кроме того, всегда следует помнить, что вообще функционирование Unix-подобной системы в значительной мере происходит в шелл-среде. Ибо шелл-сценариями являются все скрипты инициализации системы, многие общесистемные и пользовательские конфигурационные файлы, такие системы управления пакетами, как порты FreeBSD и портежи Gentoo Linux. Ну и то, что любой пользователь свободных ОС рано или поздно начинает писать собственные сценарии оболочки - неизбежно, как распад мировой системы социализма (кто еще не начал - уж поверьте мне на слово, хотя скажи мне такое лет пять назад - ни в жисть бы и сам не поверил).

Сказанного, думаю, достаточно, чтобы отнестись к выбору шелла со всей ответственностью. Причем при выборе этом должно учитываться два аспекта применения шелла - как среды для пользовательской работы, так и системы для исполнения общесистемных и пользовательских сценариев.

Первый аспект охватывается понятием интерактивный шелл. Это - любой экземпляр командной оболочки, запущенный пользователем непосредственно. Если этот экземпляр запускается при входе пользователя в систему, его называют login shell (то есть главная пользовательская оболочка).
Очевидно, что login shell - также интерактивен, однако в сеансе работы каждого пользователя он будет единственным. Просто же интерактивных шеллов можно запустить сколько угодно - например, в каждом окне эмулятора терминала в Иксах будет функционировать собственная копия интерактивного шелла.

Имя исполняемого файла, запускающего login shell (вместе с полным путем к оному - например, /bin/sh) - атрибут учетной записи каждого реального пользователя системы. Теоретически в этом качестве могут выступать не только собственно шеллы (то есть командные оболочки), но и интерпретатор какого-либо языка программирования (например, Tcl), программа типа Midnight Commander или даже текстовый редактор. Однако эти случаи - специальные, и далее рассматриваться не будут.

Второй аспект использования шелла - неинтерактивный. Неинтерактивный шелл - это экземпляр командной оболочки, вызываемый при выполнении пользователем любой команды или любого сценария. Он может быть вызван неявным или явным образом. Первый случай имеет место быть при выполнении команды из строки оболочки - ведь в этом случае, как мы видели в , посредством системного вызова fork создается точная копия породившего процесса (то есть той же интерактивной оболочки), а уже она вызовом exec запускает на исполнение введенную пользователем команду. Явный же вызов шелла происходит при выполнении сценариев оболочки - любой из них запускает собственный экземпляр командного интерпретатора.

При составлении пользовательского или системного сценария шелл, вызываемый для его исполнения, можно указать явным образом - и настоятельно рекомендуется этой возможностью пользоваться. Делается это в первой строке скрипта, называемой sha-bang, которая по правилам должна иметь вид вроде

#!/bin/bash

То есть после символов решетки (#) и восклицания (! - видимо, для пущей экспрессии) следует указывать полный абсолютный путь к исполняемому файлу, оболочку запускающему. Делается это, в том числе, и во избежание недоразумений - так, просто единичный символ решетки в первой строке может быть интерпретирован не как комментарий, а как указание на запуск командной оболочки csh.


И если сценарий был написан не для нее (а, например, для того же /bin/sh) - он, в силу различия синтаксиса, просто не будет выполнен.

Подчеркнем еще раз: хотя команда, запускающая интерактивный или неинтерактивный шелл, может носить то же имя, что и команда на запуск login shell (а в Linux, скажем, обычно так и есть), это - разные экземпляры программы, которые в общем случае могут быть настроены независимо. А значит - и вести себя разным образом. И потому не следует удивляться, когда bash в эмуляторе терминала не реагирует на управляющие клавиши, привычные для того же bash в виртуальной консоли. А Midnight Commander отказывается в своей командной строке опознавать пути к исполняемым файлам.

Очевидно, что претензии пользователя к интерактивному (особенно к пользовательскому login shell) и неинтерактивному шеллам могут быть разными. В первом случае, как явствует из названия, важнее всего удобство интерактивной работы - развитые средства автодополнения, работы с историей команд, возможности гибкой и информативной настройки приглашения командной строки. Для неинтерактивного же шелла на первый план выходят быстродействие и совместимость.

С быстродействием все понятно - когда единственной задачей командной оболочки является вызов на исполнение другой команды (или, в случае скрипта, серии связанных команд) - тратить ресурсы на обеспечение дополнительных возможностей было бы излишеством. А вот о совместимости следует сказать особо. Но сначала - несколько слов о том,


Принципы конфигурирования


Поведение конкретного экземпляра шелла того или иного вида определяется, кроме принадлежности к одному из описанных семейств, также и файлами его конфигурации. Практически все широко используемые шеллы, которые упомянуты в предыдущем разделе, имеют минимум два конфига - т.н. профильный файл (profile), считываемый при запуске login shell (сиречь главного пользовательского шелла), и rc-файл, из которого берутся настройки любого шелла интерактивного. В некоторых оболочках предусмотрен еще и конфиг, обращение к которому происходит при запуске любого экземпляра шелла, в том числе и неинтерактивного. А подчас предусматривается и конфигурационный файл для завершения данного шелл-сеанса (очевидно, что он имеет смысл только для login shell).

Содержание профильного файла, как правило, - это переменные среды, которые должны наследоваться всеми процессами, как запущенными командами из строки пользовательского шелла, так и теми, что запускаются из пользовательских сценариев. В их числе такие, как тип терминала (переменная TERM), каталоги для поиска исполняемых файлов и man-страниц (переменные PATH и MANPATH, соответственно), имя редактора и pager'а по умолчанию (EDITOR, PAGER). В rc-файл резонно помещать переменные переменные оболочки и псевдонимы команд, имеющие смысл только для интерактивно запускаемых экземпляров шелла. Впрочем, это не обязательно - подчас профильный файл содержит единственную строку, предписывающую прочитать содержимое rc-файла для данного шелла (в котором и определяются все параметры пользовательского окружения).

Имена конфигурационных файлов различны в разных оболочках. В sh-совместимых оболочках конфиг для login shell обычно имеет в своем имени слово profile (откуда и пошло - профильный файл), имя интерактивного конфига образуется по модели shell_namerc. Место размещения общесистемных шелловских конфигов - обычно каталог /etc - эти файлы будут считываться в любом случае для login shell любого пользователя, и для любого экземпляра запущенного каждым пользователем интерактивного шелла.
И их изменение - компетенция исключительно администратора системы.

Однако каждый пользователь имеет возможность создать также свои собственные файлы конфигурации для своего login shell (и любых шеллов, запускаемых им интерактивно или из собственных сценариев). Они располагаются в корне домашнего каталога пользователя (~/), обычно одноименны общесистемным, но предваряются символом точки - почему и называются dot-файлами (это, впрочем, относится к пользовательским конфигурационным файлам практически любых программ). Пользовательские конфиги считываются после общесистемных, и потому содержащиеся в них параметры перекрывают, дополняют или отменяют значения параметров общесистемных.

А относительный порядок считывания профильного и rc-файла также различен в разных оболочках, и сложился он исторически. Первый шелл Борна имел один-единственный набор конфигов - общесистемный /etc/profile и пользовательские ~/.profile). И когда в его клонах появились отдельные конфиги для интерактивных шеллов - они считывались после профильного в таком порядке:

/etc/profile -> /etc/shrc -> ~/.profile -> ~/.shrc

В C-shell изначально имелось два конфига - общий cshrc и login - конфиг для пользовательского шелла. Причем первый считывался при старте любого экземпляра шелла, в том числе и запускаемого при авторизации. Лишь после этого определялось, является ли данный экземпляр шелла пользовательским, и если да - происходило считывание файла login:

/etc/csh.cshrc -> /etc/csh.login -> ~/.cshrc -> ~/.login

Имена C-конфигов могут меняться в разных ОС и дистрибутивах (приведенный пример относится к FreeBSD и DragonFlyBSD). Однако порядок обращения к ним унаследован современным свободным клоном C-shell - tcsh (именно он под именем /bin/csh фигурирует на самом деле во всех BSD-системах).

Порядок обращения к конфигурационным файлам не есть нечто данное от века - в сущности, он определяется при компиляции данной оболочки (как - в конкретном случае можно посмотреть из вывода сценария конфигурирования ./configure --help перед компиляцией).


И может быть изменен на противоположный, более того - имена конфигов могут быть изменены произвольным образом, или для разных оболочек могут быть установлены одни и те же конфиги. Однако в большинстве случаев с прекомпилированными шеллами он по умолчанию именно таков, как я описал выше.

Да, чуть не забыл сказать: в приведенных примерах молчаливо предполагалось, что исполняемый шелл и его общесистемные конфиги находятся непосредственно в подкаталогах корня файловой системы (/bin и /etc, соответственно). Это отнюдь не обязательно: например, файлы bash bkb zsh, установленных из портов FreeBSD, будут иметь своим местопребыванием по умолчанию подкаталоги в /usr/local, в дистрибутивах Linux все оболочки, кроме общесистемной bash, окажутся, скорее всего, в подкаталогах /usr, и так далее. Однако очень важно, чтобы login shell пользователя root был собран (с помощью соответствующих опций, о чем говорилось в ) так, чтобы его исполняемый файл и конфиг инсталлировались бы именно в /bin и /etc: иначе они окажутся недоступными в однопользовательском режиме, когда такие ветви файловой системы, как /usr и /usr/local, могут быть просто не смонтированы.


Проблема выбора


Из приведенного краткого обзора можно видеть, что в плане шеллов выбор пользователя достаточно обширен. А ведь я остановился только на самых распространенных. Однако рискну предположить, что большинство начинающих пользователей Linux'а об этом не особо задумываются. Ведь во всех его дистрибутивах в качестве общесистемного шелла и пользовательского шелла по умолчанию принят bash, обладающий как развитыми средствами интерпретации, так и продвинутыми интерактивными возможностями, да еще при сохранении совместимости со стандартом. Так зачем, казалось бы, искать добра от добра?

Первый вариант ответа очевиден - добро это дополнительное ищется в тех случаях, когда необходима минимизация ресурсов. Когда bash, занимающий более полумегабайта на диске (и около полутора - в памяти) оказывается излишне громоздким и медленным. Впрочем, первое играет роль только для всяких rescue-систем на дискетах (и прочих "мелких" носителях), а второе на современных машинах нечувствительно. Тем не менее, маленький и быстрый шелл Альмкивста (ash) может оказаться подходящим не только в спасательных целях, но и для всякого рода скриптинга. Хотя работать в строке ash регулярно мне бы не хотелось...

Вторая причина поиска нового шелла - неудовлетворенность возможностями имеющегося. Эта проблема остро встает перед пользователями FreeBSD - уж очень убог его умолчальный login shell для обычного пользователя (/bin/sh) в плане интерактивной работы. Что особенно наглядно проступает в сравнении с могучим tcsh, каковой по определению получает в свое распоряжение root-оператор. А потому и простой юзер может поддаться искушению и выбрать себе тот же tcsh - хотя бы ради единства стиля работы (ведь на настольной машине тот же юзер, как правило, сам себе root).

Должен заметить, что именно при первом приобщении к FreeBSD я и перепробовал целый ряд доступных в ней шеллов. Благо через систему портов или коллекцию пакетов они столь же легко удалялись, как и устанавливались. Не обошел я своим вниманием и tcsh - и в целом остался им доволен.
Как интерактивная оболочка tcsh, на мой взгляд, существенно превосходит bash. А простой, логичный и лаконичный синтаксис его языка немало способствует в деле шелл-скриптинга. Правда, в этом и кроется, пожалуй, единственный недостаток tcsh: даже виртуозное им владение не освобождает от необходимости хоть как-то изучать какой-либо POSIX-совместимый шелл - ведь общесистемные сценарии все равно пишутся на нем...

И, наконец, третья причина для изысканий - поиски идеала. А не они ли движут, осознанно или нет, изрядной долей пользователей свободных POSIX-систем? Спору нет, bash - оболочка хорошая, но до такого идеала явно не дотягивающая, слишком много в нем направлено на достижения баланса компактности и функциональности. И тут стоит присмотреться к Z-Shell, или просто zsh - оболочке с лучшими, пожалуй, интерактивными возможностями.

Итак, круг знакомств очерчен - остается к этому знакомству приступить. Приводимые ниже описания наиболее распространенных шеллов поневоле будут очень разной степени глубины и подробности, ведь я руководствуюсь исключительно собственным, неизбежно ограниченным, опытом и своими, сугубо субъективными, симпатиями.


Sh-совместимые оболочки


Оболочку ash (и практически идентичный ей /bin/sh из FreeBSD) можно рассматривать в качестве POSIX-шелла par excellence. Интерактивные ее возможности проще всего охарактеризовать в сранении с более "продвинутыми" шеллами - и исключительно от противного. А именно: она не поддерживает автодополнения, не имеет удобных средств доступа к истории команд, и даже средства навигации по командной строке и редактирования оной сводятся к клавише Backspace и ее эквиваленту - Control+H. Встроенных команд также немного (около 20 десятков).

Что же остается в сухом остатке? Остается поддержка командных конструкций (перенаправления и конвейеров), возможность фонового выполнения команд, определения псевдонимов и функций. Вряд ли этого достаточно для комфортной интерактивной работы. А вот для сочинения сценариев и их исполнения - довольно вполне. Более того, скрипты, написанные для исполнения в чистом шелле, то есть имеющие sha-bang вида

#!/bin/sh

будут исполняться в любой POSIX-совместимой системе, так как каждая из них содержит исполняемый файл sh - и именно в каталоге /bin.

Средства настройки /bin/sh также не блещут разноообразием. Штатно для этой оболочки предусмотрен единственный файл - /etc/profile (и парный ему пользовательский профильный файл - ~/.profile), считываемый при авторизации. Однако, как мы только что выяснили, применять /bin/sh в качестве login shell не очень удобно, а все прочие его экземпляры таким образом оказываются без всяких настроек окружения вообще - что тоже не есть хорошо. И потому для /bin/sh можно установить и второй конфиг, однако этот факт, как и имя такого файла, необходимо определить явным образом в /etc/profile (или в ~/.profile), например, таким образом:

ENV=etc/shrc; export ENV

или, соответственно, так:

ENV=$HOME/.shrc; export ENV

Это увеличивает гибкость настроек /bin/sh, приближая его к более развитым аналогам.

Следующей sh-совместимой оболочкой является bash. Ей посвящено немерянное число материалов, к которым я, не являясь ни ее любителем, ни, тем более, знатоком, добавить ничего не могу.
Однако bash - наиболее распространенная среди пользователей Linux командная оболочка, выступающая в этой ОС к тому же общесистемной и умолчальной. Популярна она, насколько мне известно, и среди пользователей иных POSIX-систем, по крайней мере свободных. И потому не сказать о ней хоть пару слов здесь - нельзя.

Оболочка bash поддерживает все интерактивные возможности, свойственные развитым шеллам, как то: автодополнение для команд и путей к файлам, историю оных (включая средства инкрементного поиска), мощные возможности навигации и редактирования командной строки. Важно, что существует дополнительный пакет bash-completion: установка его обогащет базовую оболочку множеством опциональных средств настройки автодопллнения (в том числе и для командных аргументов).

Схема инициации bash предусматривает наличие пары файлов /etc/profile и /etc/bashrc (для пользовательского шелла и просто интерактивного его экземпляра, а также соответствующих им пользовательских конфигов - ~/.bash_profile и ~/.bashrc. Однако порядок их считывания имеет некоторую спцифику. При авторизации первым в любом случае считывается общесистемный профильный файл /etc/profile, вслед за ним - пользовательский профильный файл ~/.bash_profile, после чего происходит обращение к ~/.bashrc. Однако порядок обращения к конфигам может быть изменен при сборке пакета, и майнтайнеры дистрибутивов Linux широко пользуются этой его особенностью. А также особым положением файла /etc/profile - в него часто помещают переменные окружения (например, локально-зависимые), которые должны быть общими для всех пользователей данной системы.

В общем, о bash можно было бы говорить еще долго. Однако достаточно заметить, что почти в любой толстой книге про Linux, когда речь заходит о командных оболочках вообще, как правило, имеется ввиду именно bash. Немало сведений о ней есть и в Сети, в том числе в русскоязычном ее сегменте. И потому в заключение ограничусь ссылками на источники информации:

BASH конспект, где кратко просуммированы все важные для пользователя данные по этой оболочке (копия); Особенности работы оболочки bash, содержащей массу сведений по использованию ее в интерактивном режиме, настройке и т.д. (копия); Advanced Bash-Scripting Guide - практически исчерпывающее руководство по программированию bash-скриптов, которое будет полезно при изучении любых Shell-совместимых оболочек.

А из "бумажных" изданий нельзя забывать о такой книге: Д. Тейнсли. Linux и Unix: программирование в shell. К.: Издательская группа BHV, 2001. В принципе она посвящена астрактному шеллу, но в ней оговорены все случаи, относимые именно к bash.

И, наконец, Z-Shell или, сокращенно, zsh. Эта оболочка также принадлежит к клану sh-совместимых. Причем существует мнение (и не только мое), что в ней нашли свое воплощение все прогрессивные тенденции таких развитых оболочек, как bash и tcsh. И, ознакомившись с его возможностями, с этим трудно не согласиться - в zsh есть все, что было хорошего в тех обеих оболочках, но, если так можно выразиться, в превосходной степени. А ознакомиться с ней можно в специальной статье.


Дополнительные элементы интерфейса


Основных элементов интерфейса (меню, главной панели и панелей пользовательских панелей) вполне достаточно для разметки html-страницы. Дополнительные же элементы (панели, обрамляющие рабочую область с трех остальных сторон) призваны повысить комфортность работы, либо же служат специальным целям.

Я упоминал уже, что quanta интегрирована с инструментами управления файлами, сконцентрированными в левой дополнительной панели.Здесь мы видим пять пиктограмм-кнопок, назначение которых выясняется из всплывающей подсказки (сверху вниз): Файлы, Проект, Дерево шаблонов, Свойства документа, Сценарии.

Как можно догадаться, нажатие на кнопку Файлы разворачивает дерево каталогов файловой системы. По умолчанию - в отдельном окне, перекрывающем как верхние панели, так и рабочую область. Однако если нажать на среднюю из трех крошечных кнопочек в правом верхнем углу этого окна, оно окажется встроенным в общую структуру интерфейсных элементов quanta, что можно видеть на рис. 23.


Рис. 23. Инструменты для файлового менеджмента гармонично вписываются в рабочую область quanta

Манипуляции с файлами в одноименном окне осуществляются через контекстное меню, вызываемое щелчком правой клавиши мыши. Здесь можно: скопировать, удалить и переименовать файл, а также каталог, просмотреть их свойства (через этот пункт меню возможен также просмотр атрибутов принадлежности и доступа и, при наличии соответствующих привилегий, их изменение).

Кнопка Проект выводит в том же окне (автономном или встроенном) дерево файлов проекта, о чем будет говориться чуть ниже. Свойства же прочих кнопок панели управления файлами, как и панелей, обрамляющих рабочую область снизу и справа, читателю предлагается изучить в качестве домашнего задания.



Дополнительные настройки


В начале своего повествования я упоминал, что ныне (начиная с версии 3.0) в joe появилась возможность подсветки синтаксиса для ряда языков программирования и разметки. Чтобы ей воспользоваться, нужно, во-первых включить соответствующую опцию в конфигурационном файле ~/.joerc - она расположена в секции Default local options и имеет вид

-highlight

Далее, требуются файлы описания цветов для синтаксических элементов различных языков. Примеры таких файлов расположены в /usr/local/etc/joe/synatx и охватывают языки Си (c.jsf), Assembler (asm.jsf), Fortran (fortran.jsf) и многие другие. Есть здесь и файлы описания языков командных оболочек (sh.jsf и csh.jsf), diff-файлов (diff.jsf), конфигов (conf.jsf), а также языков разметки (html.jsf и xml.jsf). Единственное, что остается с ними сделать - это отредактировать их в соовтетствие с предпочтительной цветовой гаммой (и сохранить в собственном домашнем каталоге под именами типа ~/.synatx/html.jsf и так далее).

Наконец, последнее - это проверить соответствие файлов описаний в главном конфигурационном файле ~/.joerc. По умолчанию в каждой языковой субсекции они указываются там в виде:

-syntax html

и так далее, в предположении их стандартных имен и размещения (в указанных выше каталогах /usr/local/etc/joe/synatx или ~/.synatx/html.jsf.



Дополнительные возможности kdewebdev


Внимательный читатель обратил внимание, что в редакторе quanta, при всем богатстве его возможностей. не обнаруживается такого важного для ведения крупных web-проектов средства, как контроль целостности ссылок, ни внутренних, ни тем более внешних. Это действительно так. Однако вспомним, что quanta - лишь один (хотя и главный) из компонентов пакета kdewebdev. Остается ознакомиться с его возможностями - не найдем ли мы там чего-либо недостающего для полного счастья?

И конечно же, найдем - программу klinkstatus, именно для проверки ссылок и предназначенную. Запускаем одноименной командой ее из командной строки или минитерминала (штатно в K-меню она отсутствует, хотя никто не мешает ее туда встроить) и видим окно следующего вида (рис. 31). Отправляемся в меню Файл -> Открыть URL, выбираем индекс-файл нашего сайта, устанавливаем требуемую глубину вложенности подкаталогов, жмем кнопку Проверить - и через некоторое время получаем полный список всех ссылок, как работающих (отмеченных зелеными галочками), так и оборванных (красные кресты). Последними на машине, в данный момент не подключенной к Сети, будут все внешние ссылки. Проверку коих при необходимости можно исключить, сняв соответствующий переключатель.


Рис. 31. Проверка целостности ссылок утилитой klinkstatus - обращаем внимание на глубину рекурсии и переключатель проверки внешних ссылок

Из рисунка можно видеть главный недостаток текущей версии klinkstatus русские заголовки страниц предстают в виде абракадабры. Впрочем, на функциональности собственно проверки ссылок это не отражается.

Программа klinkstatus не блещет богатством настроек (рис. 32), хотя все жизненно необходимое тут присутствует. А именно - задание "умолчальных" глубины рекурсии, включения/отключения проверки внешних ссылок, число адресов в истории и т.д.


Рис. 32. Настройка klinkstatus

В составе пакета kdewebdev есть еще несколько полезных утилиток. Например:

kimagemapeditor, программа для создания т.н. карт изображений, то есть разбиения рисунка на отдельные области, к каждой из которых привязана гиперссылка;


kmdr-editor - редактор диалогов;

xsldbg - отладчик XSL, работающий в командном режиме, и графический интерфейс к нему - kxsldbg.

Однако их рассмотрение далеко выходит за рамки темы этой главы. Замечу только, что все эти средства могут быть и интегрированы в quanta в качестве модулей. По умолчанию это сделано для klinkstatus, kimagemapeditor и xsldbg. То есть они могут вызываться из меню редактора - через пункт Модули и далее Link Checker, KImageMapeditor или XSLT Debugger, соответственно.

В меню Модули можно обнаружить еще один пункт - KFileReplace, пользу которого трудно переоценить. Он позволяет выполнить поиск и замену текстовых фрагментов в группе файлов (например, в каталоге, включая вложенные подкаталоги) в пакетном режиме. Каждый, кому приходилось менять адрес электронной почты web-мастера на сотнях страниц своего сайта, проникнется величием такой возможности.

Допускается в quanta и подключение дополнительных модулей - через меню Настройка -> Настроить модули. Правда, для этого их кто-то должен написать. Но в качестве дополнительных модулей могут использоваться составные KPart из kate - а их пишут довольно активно.


Текстовые редакторы


Думается, не будет большим преувеличением сказать, что из всех приложений POSIX-подобных операционок важнейшим являются текстовые редакторы. Тем более, что они лежат на грани программ общесистемных и пользовательских. Ведь с помощью редактора (а иногда - и исключительно при его посредстве) настраивается система, редактируются общесистемные и пользовательские конфиги, пишутся скрипты и сценарии. А некоторые юзеры, подобно вашему покорному слуге, даже используют текстовый редактор и по прямому назначению - просто для составления повествовательных текстов.



Главные элементы интерфейса


Функции обработки html-материалов реализованы в quanta посредством весьма специфического интерфейса. Рисунок 21 показывает примерный вид редактора по умолчанию. Можно видеть, что собственно рабочее поле - область редактирования html-кода (а режим прямого редактирования здесь основной), - обрамлено множеством инструментальных панелей и прочих интерфейсных элементов.


Рис. 21. Web-редактор quanta - интерфейсные элементы по умолчанию

Вдоль верхней границы рабочей области имеем (сверху вниз): а) строку главного меню; б) главную инструментальную панель; в) панель закладок, в которые сгруппированы теги, и г) соответствующую каждой закладке собственно панель тегов.

О главном меню можно говорить или очень много, или ничего. Поэтому отмечу только, что через него осуществляется доступ ко всем функциям программы, которые в принципе доступны. Ну а смысл каждого пункта и подпункта ясен либо из его названия (при установке русской KDE-локали интерфейс quanta, как и всех KDE-приложений, оказывается русскоязычным, и сложностей с пониманием не возникнет даже при незнании английского языка), либо (в редких случаях) устанавливается методом ползучего эмпиризма.

Не буду распространяться и на тему главной инструментальной панели: при наведении на любую ее пиктограмму всплывает исчерпывающая (и русскоязычная) подсказка.

А вот о закладках и соответствующих панелях тегов (в терминологии quanta они именуются пользовательскими панелями инструментов) стоит сказать подробнее: именно через них мы в дальнейшем будем выполнять тонкую индивидуальную настройку редактора.

По умолчанию закладок шесть:

Стандартная

Стиль

Таблицы

Списки

Формы

Прочие

Смысл их более-менее понятен из названий, однако некоторые комментарии все же лишними не будут.

Панель Стандартная объединяет элементы, используемые постоянно в ходе разметки тела html-страницы: параграфы и разрывы строки, гиперссылки и вставки изображений, выделения и выравнивания. Стоит отметить, что полужиному и курсивному выделению соответствуют не визуальные теги и , а структурные теги и , а выравнивание достигается значениями атрибутов тега .
Вообще, весьма точное следование букве спецификаций W3C - одна из характерных черт редактора quanta.

В панель Стиль объединены теги для заголовков (с 1-го по 4-й уровень), преформатированного текста, верхних и нижних индексов, цветового выделения, а также для работы со стилевыми таблицами (CSS).

Пиктограммы панели Таблицы позволяют создать таблицу целиком (Редактор таблиц) - с требуемым числом строк и колонок, с заголовком, шапкой, примечаниями и даже данными. Возможно и поэлементное создание таблицы в абсолютно любой последовательности.

Панель Списки предназначена для создания именно этих элементов html-разметки - нумерованных и ненумерованных списков (ordered lists и unordered lists, соответственно) и их элементов (list items), а также списков определений (definition lists).

Панель Формы служит для создания простых интерактивных элементов web-страницы - форм, выпадающих меню, переключателей, радиокнопок и т.д.

Наконец, в панель Прочие попало несколько пиктограмм, не охваченных в предыдущих закладках, как то: вставка даты/времени, ссылки на адрес электронной почты, метатегов, мнемонических кодов для замены специальных символов (типа символа копирайта и "собаки" - во избежания спамового завала в адресах электронной почты вместо @ лучше использовать его эквивалент @, мастер создания фреймовой структуры.

Очень важна пиктограмма Прочие теги. Во-первых, внимательный просмотр пользовательских панелей и пункта Теги главного меню показывает, что все многообразие тегов современного html не охвачено ни там, ни там. И потому, если потребуется вставить тег типа , придется обратиться к этой кнопке. Во-вторых, элементы xml-разметки в quanta также не предусмотрены - их на первых порах придется задавать посредством пиктограммы Прочие теги. Хотя в дальнейшем мы увидим, что и ту, и другую операцию легко автоматизировать.

Все кнопки пользовательских панелей можно разделить на две группы - обычные и диалоговые. Нажатие первых вызывает вставку простого тега (при необходимости - как отрывающего, так и закрывающего), например, параграфа или разрыва строки.Диалоговые же кнопки связаны с тегами, требующими (или допускающими) указания атрибутов и их значений. В этом случае вызывается диалоговая панель, в соответствующих полях которой можно указать требуемые параметры, как это можно видеть на примере тега



Рис. 22. Указание значений атрибутов для тега при вставке изображения в html-страницу

Редактировать значения атрибутов тегов можно и иным способом: достаточно щелкнуть правой клавишей на теге, допускающем указание таковых, - и в появившемся контекстном меню выбрать пункт Редактировать тег для вызова той же диалоговой панели.


Характерные особенности


Для эффективного использования joe следует четко уяснить, что это - командный редактор в чистом виде. То есть все действия по редактированию текста осуществляются соответствующими встроенными командами, к которым привязаны комбинации клавиш. В сущности, как будет показано ниже, это - макросы на собственном языке joe. Из чего следует, что, с одной стороны, система команд может быть сколь угодно наращена, с другой - что клавишные комбинации для них могут быть переопределены произвольным образом.

Впрочем, необходимости в последнем я не вижу. Структура предопределенных по умолчанию клавишных комбинаций проста и очень логична. За самыми простыми и частыми действиями для навигации и редактирования закреплены двухклавишные комбинации. Это, как правило, сочетание одновременно нажатых клавиш Control и буквенной. Последняя имеет, обычно, мнемонический смысл, хотя и не всегда прозрачный.

Полный список встроенных команд и привязанных к ним клавишных комбинаций дан в заключительном разделе этой статьи. Здесь же я приведу только основные примеры. Так, комбинация Control+B (от backward) перемещает курсор на один знак влево, Control+F (от forward) - на один знак вправо, Control+Z - переход к предыдущему слову, Control+X - к последующему слову, и так далее.

В некоторых случаях в качестве управляющей клавиши используется клавиша Meta (напомню, что ее эквивалент - нажатие и отпускание клавиши Escape): если в комбинации с ней набрать литеру W - курсор переместится на строку вверх, литеру Z - на строку вниз. Кроме того, Meta служит для вызова проверки правописания для слова (Meta+N) и всего файла (Meta+L). Нажатие клавиши Meta два раза подряд приводит к установке закладки (bookmark), которая маркируется произвольной цифрой, а Meta+# (где # - эта самая цифра) вызывает переход к установленной закладке. Правда, очевидно, что закладок не может быть больше 10; и к тому же по завершении сеанса они не сохраняются.

Все клавишные комбинации в joe не чувствительны к регистру, причем не только для буквенных, но и символьных клавиш.
Так, для отмены последней операции ( как уже говорилось, многоуровневой) зарезервирована комбинация Control+_ (знак подчеркивания), а для возврата отмененного действия - Control+^; однако в первом случае работает также комбинация Control+- (дефис или минус), во втором - Control+6.

Кроме того, все двухклавишные комбинации не чувствительны и к раскладке клавиатуры: сочетание клавиш, например, Control+T будет вызывать систему настройки joe и при кириллической раскладке. Интересно, что для пролистывания страниц помощи вперед и назад при кириллической раскладке следует нажимать Escape и точку (или, соответственно, запятую) также в ее положении на русифицированной клавиатуре (то есть в нижнем правом углу для Windows-клавиатур и на верхнем регистре цифр 5 и 7, если мне не изменяет память, - для клавиатур с DOS-маркировкой).

Для более сложных или редких действий используются трехклавишные комбинации. Это почти исключительно одновременно нажатые Control+K, после чего нажимается литерная клавиша. Так, операции с блоками осуществляются следующим образом:

Control+K - B отмечает начало выделяемого блока,

Control+K - K - его конец,

Control+K - C - копирует,

Control+K - M - перемещает выделенный блок в позицию курсора,

и так далее. Трехклавишные комбинации также не чувствительны к регистру. И работают также и при кириллической раскладке клавиатуры. В этом случае только необходимо нажимать вторую литерную клавишу вместе с той же клавишей Control: то есть запись текущего файла при включении кириллической раскладки потребует комбинации Control+K - Control+D, вызов нового файла - Control+K - Control+E, и так далее.

В joe нет отдельной функции для переименования файла. Но при любой записи текущего документа следует запрос на подтверждение имени файла, изменить которое при этом никто не запрещает. Следует только помнить, что дальнейшая работа происходит с исходным, а не переименованным файлом.

Кроме того, в joe доступны еще некоторые действия с файлами.


Так, комбинация Control+K - R вставляет текст из существующего файла в позицию курсора, Control+K - W - записывает выделенный блок в виде нового файла (разумеется, запросив предварительно его имя). С помощью комбинации Control+K - E можно открыть для редактирования другой существующий файл. При этом следует предложение ввести путь и имя, причем и для того, и для другого работает режим дополнения клавишей табуляции, как в командных средах bash или tcsh.

Между одновременно открытыми файлами возможен обмен данными: или с помощью команд joe (то есть выделением блока в первом файле и его копированием или перемещением во второй), или с помощью мыши - стандартным выделением и вставкой щелчком средней ее клавиши. Второй способ, естественно, может применяться и для обмена между разными копиями joe, запущенными на отдельных виртуальных консолях.

Одновременно открытые файлы могут быть представлены как в полноэкранном виде, так и каждый в своем окне. Для переключения между однооконным и многооконным режимами служит комбинация Control+K - I. Размер каждого из выведенных окон может быть увеличен или уменьшен (Control+K - G и Control+K - T, соответственно), правда, только с шагом в одну экранную строку. Переключение между открытыми документами, вне зависимости от режима, осуществляется комбинациями Control+K - N (вперед или вниз) и Control+K - P (назад или вверх).

К слову сказать, в joe возможен и независимый просмотр разных частей документа в отдельных окнах, для чего предназначена функция расщепления окна (Control+K - O). Ну и, конечно же, фрагменты из одной части файла могут быть легко перенесены в другую.

Универсальной комбинацией для окончания любой операции в joe является Control+C. С ее помощью закрывается окно с текущим документом; если он был единственным в данном сеансе, одновременно происходит и выход из редактора. В обоих случаях следует запрос на сохранение изменений, буде таковые имелись. Отказаться от выхода или закрытия файла можно повторным нажатием той же комбинации Control+C.


Она же используется для прекращения любой длящейся во времени (спеллинг, поиск) или требующей подтверждения операции.

Кроме этого, непосредственно из joe, без выхода, можно обращаться к командам оболочки (shell), причем - различными способами. Так, комбинация Control+K - Z обеспечивает временный выход в оболочку, где можно вводить любые ее команды. А по завершении операций - вернуться в среду joe можно комбинацией fg. То есть в данном случае мы имеем дело с обычной приостановкой текущей задачи.

Кроме этого, есть и более интересная возможность: открытие внутри joe, посредством комбинации Control+K - '

(апостроф), самостоятельного окна с собственной командной оболочкой. Здесь можно выполнять любые команды с выводом их результатов на экран. После чего стандартной командой exit осуществляется выход из среды, а все результаты сохраняются обычным для joe образом в виде текстового файла: возможность неоценимая при создании и редактировании всякого рода скриптов.

Следует подчеркнуть, что в данном случае запускается именно встроенная в joe оболочка, не имеющая никакого отношения к пользовательской (login shell). Она не порождает нового процесса (в чем легко убедиться командой ps) и не наследует никаких переменных окружения от пользовательской оболочки. Интерактивные ее возможности достаточно слабы (не поддерживаются ни автодополнение, ни история команд). Однако она дает возможность интеграции возможностей joe по редактированию и команд оболочки для обработки текста (о которых - см. ).

Единичная команда оболочки может быть выполнена после нажатия комбинации клавиш Meta+!. В этом случае внизу экрана появляется приглашение командной строки в форме:

Program to run:

представляющее собой разновидность встроенной оболочки joe.

Наконец, в joe обеспечивается ввод специальных символов. Так, нажатие клавиши ` (обратный апостроф) приводит к предложению ввести первый знак десятичного (0-9), шестнадцатеричного (x) или восьмеричного (o) кода символа. Если же вместо кода нажать Escape - можно ввести любую esc-последовательность.То же самое можно сделать и после нажатия комбинации Control+\.

Специальные символы могут вводиться не только непосредственно в редактируемом тексте, но и в строке поиска. Это позволяет легко находить и глобально заменять лишние разрывы строк и тому подобные нарушения структуры.

Таковы основные возможности joe для редактирования текстов общего характера. Кроме этого, имеется ряд команд специального назначения, используемых при программировании (поиск ошибок, компилирование и прочего). Однако и сказанного достаточно для представления возможностей редактора joe.


Интермедия: html-редактор Quanta Plus


Составление web-документов - частный случай работы с текстами вообще. И потому эта интермедия посвящается системе разработки web-приложений Quanta Plus - программе, начавшей свое существование как обычный редактор html-кода, но быстро переросшей эти рамки. Она требует предварительного знакомства с .



я коснулся лишь некоторых особенностей


В этой главе я коснулся лишь некоторых особенностей программы quanta - тех, которые наиболее важны для меня лично. За чертой рассмотрения остались такие вещи, как работа с XML, стилевыми таблицами, сценариями - то, что требуется профессионалу в области web-технологий, к каковым себя не причисляю. А потому подведу предварительные итоги.
Думаю, мне удалось продемонстрировать как широту возможностей описываемого редактора (особенно в сочетании с дополнительными модулями), так и гибкость его индивидуальных настроек. Конечно, мне давно не приходилось видеть редакторов html-кода для Windows, однако по смутным воспоминаниям о HomeSite - как будто бы в нем не было ничего такого, что невозможно было бы реализовать в quanta - штатными ли ее средствами, или с помощью модулей. Включая даже режим визуального редактирования, о котором я практически не говорил - ввиду тривиальности приемов работы в нем.
Так что думается, что значение этой программы выходит за рамки сочинения любительских web-страниц - это вполне полноценный и профессиональтный инструмент web-мастера. Ну а его возможности по составлению html-документации - просто выше всяких ожиданий. В частности, окончательная версия этой книги доводилдась до ума именно в Quanta Plus.

Joe: гармония простоты и функциональности


Редактор joe принадлежит к категории public domain, то есть общественного достояния: мало кто помнит, кто и когда написал его первую версию. И долгое время он пребывал в состоянии практической консервации. Пока наконец в этом проекте не наметилась определенная активность, ознаменовавшаяся выходом версий серии 3.X. Которые привнесли несколько кардинальных новшеств, сделавших исходно хороший редактор еще лучше...



Макрокоманды


Если же штатных команд редактора joe оказывается недостаточно, можно прибегнуть к их самостоятельному конструированию. Для чего предназначен внутренний язык макрокоманд. К сожалению, он не описан в экранной документации. Однако получить представление о его синтаксисе и возможностях можно, изучив внимательно конфигурационный файл joerc (о чем подробнее - в следующем разделе).

Кроме того, есть еще один простой и эффективный способ изучения макроязыка, совмещающий приятное с полезным, - режим протоколирования макрокоманд. Включается он комбинацией клавиш Control+K - [ (открывающая квадратная скобка), вслед за чем следует ввести номер макроса (от 0 до 9), выступающий как в качестве его имени, так и в роли запускающей клавиши. Далее просто выполняются необходимые действия (например, вводится требуемый тэг html), после чего запись макроса останавливается комбинацией Control+K - ] (закрывающая квадратная скобка). Для воспроизведения запротоколированного макроса используется комбинация Control+K - # (где # - указанный при записи номер макрокоманды).

С помощью протоколирования макросов можно автоматизировать ввод наиболее нужных для конкретной задачи символов и их наборов, не предусмотренных штатным образом. Например, основных тэгов html для разметки web-страниц, таких, как параграф, разрыв строки, заголовки нескольких уровней, таблицы и списки. А заодно - и изучить синтаксис языка. Поскольку в joe

предусмотрена возможность помещения запротоколированных в данном сеансе макросов в тело существующего или нового документа (комбинацией клавиш Meta+D).

Например, записанные мной макросы для ввода html-тэгов выглядят следующим образом:

General Structure insf,"~/blank.html",rtn ^K .k1 HTML Page "",ltarw,...,ltarw .k1 H1 rtn,"",ltarw,...,ltarw .k2 H2 rtn,"\09","",ltarw,...,ltarw .k3 H3 rtn,"\09","\09","",ltarw,...,ltarw .k4 H4

Body Text rtn,"

","

",ltarw,...,ltarw .k5 Paragraph rtn,"


" .k6 Break rtn,"",rtn,"",uparw .k7 Preformat "",ltarw,...,,ltarw .k8 Strong "",ltarw,...,ltarw .k9 Emphasis rtn,"",rtn,"",uparw ^K .k8 Division

Lists and Tables rtn,rtn,"",rtn,"",uparw ^K .k2 Unordered List rtn,"",rtn,"",uparw ^K .k3 Ordered List ",",ltarw,...,ltarw ^K .k4 List Item rtn,"",rtn,"

",uparw ^K .k5 Table

Из чего вполне можно составить представление о командах языка: в первой колонке следуют разделяемые запятыми (без пробелов!) зарезервированные команды (rtn - Enter, ltarw - Left, uparw - Up и т.д.) и вводимые символьные значения в парных кавычках ("<p>"). Далее идут разделенные табулятором клавишные комбинации (^K 0 - Control+K - 0), закрепленные за макросами, и имена макросов. Последние в оригинале представлены в виде Macro 0, Macro 1 и т.д. Но никто не запрещает при редактировании придать им осмысленные имена. Да и сами макросы могут быть отредактированы должным образом в текстовом редакторе (том же joe, например).

Легко сообразить, что за один прием можно запротоколировать не более 10 макросов (маркированных цифрами от 0 до 9). Более того, они будут действовать только в течении данного сеанса: по выходе из редактора записанные макросы сами собой не сохраняются. Что, казалось бы, напрочь обесценивает данную возможность.

К счастью, это не так. И раз запротоколированные макрокоманды можно сохранить для дальнейшего использования. Да и количество их не обязано ограничиваться десятью. Как этого добиться?

Выясняется, что за воспроизведение макросов отвечает конфигурационный файл ~/.joerc, о котором подробнее будет сказано в следующем разделе. И потому достаточно поместить (с помощью Meta+D или из текстового файла) в соответствующую его секцию (какую - также скажу позднее) созданные команды, чтобы обеспечить их исполнение во всех последующих сеансах.

Более того, назначенные по умолчанию клавишные комбинации не являются обязательными.И их можно вручную заменить на любые другие, из числа не использованных ранее. После чего можно начать протоколирование команд сначала, нумеруя их от 0 до 9. Затем - повторить процедуру встраивания их ~/.joerc, и так далее, сколько потребуется (или до исчерпания комбинаторики клавиш). А поскольку количество незадействованных в joe клавишных комбинаций очень велико, то реально число созданных пользователем макрокоманд ограничивается только его фантазией и потребностями.

Таким образом можно легко автоматизировать процесс ввода тэгов HTML или XML, конструкций JavaScript, скриптов командной среды, разметки документов TeX, а также все, что потребуется впредь. Превратив joe в специализированный инструмент для решения почти любых задач.


Nano: входной билет к мир редакторов


Редактор nano вполне может сыграть роль своего рода амортизатора для начинающего пользователя. Да, это не emacs, и даже не joe. Но с задачей конфигурирования справляется успешно. А в освоении и`обращении - прост, как грабли. Не случайно во многих Source Based дистрибутивах он предлагается в качестве общесистемного. В Gentoo Linux же, где при установке необходимость в ручном редактировании конфигурационных файлов возникает весьма часто - так это просто единственный редактор, доступный на стадии инсталляции системы.

Итак, представляю: редактор nano, или, точнее, GNU nano. Официальным местопребыванием имеет сайт http://www.nano-editor.org. Генетически связан с pico - текстовым редактором, входящим в почтовый пакет pine, но, в отличие от него, распространяется на условиях лицензии GPL (и, что немаловажно, не тянет за собой почтовой системы - возможно, не всем нужной). Характеризуется авторами как маленький и дружелюбный. Что в целом соответствует истине.

Редактор nano чисто консольный и запускается из строки шелла одноименной командой, можно - с указанием имени файла, существующего или нового (в последнем случае, как обычно, файл с таким именем будет создан). Поддерживается несколько опций командной строки, как то: -T #, устанавливающей величину (в символах) табуляции, -i, включающей автоматические отступы, -w, отключающей режим переноса строк на границе экрана (что очень важно при редактировании конфигурационных файлов), и так далее. Полный их список можно посмотреть посредством

$ man 1 nano

После запуска nano перед глазами возникает нечто вроде следующего. Верху - титульная строка, в которой выводятся номер версии программы, имя открытого файла и, в правом углу, сообщение о том, что файл был изменен. В нижней части экрана можно видеть зону подсказки - список основных из управляющих клавишных последовательностей (образованных сочетанием Control+литера) с пояснениями на языке установленной локали.

Область между титульной строкой и зоной подсказки - рабочая, в ней осуществляется ввод и редактирование текста.
В nano предусмотрен ( в отличие, например, от vi и vim) только один режим работы. То есть текст вводится обычным образом, а для вызова команд предусмотрены управляющие последовательности.

В nano существует два вида управляющих последовательностей - Control+литера и Meta+литера. Посредством первых (частично дублируемых функциональными клавишами F1-F12) осуществляется редактирование текста и операции с файлами. Meta-последовательности предназначены для изменения настроек редактора (тот же результат достигается и опциями командной строки).

Напомню, что на клавиатуре PC роль Meta-клавиши выполняет обычно нажатие клавиши Alt (в некоторых раскладках - конкретно Alt'а правого, или, напротив, левого), или нажатие и отпуск клавиши Escape.

Control-последовательности - следующие (в скобках - дублирующие функциональные клавиши и, иногда, Meta-последовательности):

Control+G (F1) - вызов меню полной подсказки;

Control+X (F2) - выход из программы;

Control+O (F3) - запись текущего файла;

Control+R (F5) - вставка файла в текущий;

Control+W (F6) - поиск текста в текущем файле;

Control+(F14 или Meta+R) - замена текста в текущем файле;

Control+Y (F7 или PgUp) - перемещение на предыдущий экран;

Control+V (F8 или PgDwn) - перемещение на следующий экран;

Control+K (F9) = удаление (Cut, вырезать) строку в позиции курсора с сохранением ее в буфере (cutbuffer);

Control+U - (F10) - вставка содержимого cutbuffer'а в строку в позиции курсора; если последняя не менялась - выполняет роль Undo (отмены), штатно не предусмотренной;

Control+C (F11) - вывод информации о положении курсора в форме вроде

[ строка 4 из 81 (4%), символ 117 из 3092 (3%) ]

Control+T (F12) - проверка орфографии (посредством установленной программы спеллинга, например, ispell);

Control+P - перемещение курсора на одну строку вверх;

Control+N - перемещение курсора на одну строку вниз;

Control+F - перемещение курсора на один символ вперед;

Control+B - перемещение курсора на один символ назад;



Control+A - перемещение курсора в начало текущей строки;

Control+E - перемещение курсора в конец текущей строки;

Control+L - перерисовка текущего экрана;

Control+^ (Meta+A) - выделение (и помещение в буфер) текста, начиная с текущей позиции курсора;

Control+D - удаление символа в позиции курсора;

Control+H - удаление символа слева от курсора;

Control+I - вставка символа табуляции;

Control+J (F4) автозаполнение текущего абзаца;

Control+M вставка символа перевода строки (CR) в позиции курсора;

Control+_ (F13 или Meta+G) - переход на указанный номер строки.

Meta- последовательности работают обычно как переключатели. С их помощью выполняются следующие действия:

Meta+C - включение/выключение постоянного положения курсора;

Meta+I - включение/выключение автоотступов;

Meta+Z - включение/выключение приостановки;

Meta+X - включение/выключение вывода зоны подсказки;

Meta+P - включение/выключение режима эмуляции редактора pico;

Meta+W - включение/выключение режима переноса слов;

Meta+M - включение/выключение поддержки мыши (только при сборке с поддержкой gpm;

Meta+K - разрешить/запретить вырезание до конца;

Meta+E - включение/выключение использования регулярных выражений (regexp).

Собственно, это и все. Функциональные возможности nano отнюдь не производят впечатления исключительно богатых. Однако со своей ролью - несложной правкой небольших конфигурационных файлов, - он вполне вполне справляется. И, к тому же, в нем предусмотрено еще и внешнее средство конфигурирования - пользовательский конфиг ~/nanorc. Выполнив в нем некоторые манипуляции, можно несколько расширить функциональность редактора, в частности, обеспечить подсветку синтаксиса.


Настройка joe


Как я уже говорил, некоторые настройки joe можно выполнить интерактивно (вызвав их комбинацией Control+T). Однако они весьма ограничены и к тому же будут иметь силу только в текущем сеансе. Более интересные и богатые возможности открываются при редактировании конфигурационного файла joerc.

Пример такого файла обнаруживается в каталоге /usr/local/etc/joerc. Перво-наперво его надлежит скопировать с свой домашний каталог и переименовать в ~/.joerc - именно этот файл ищется в первую очередь при загрузке редактора. А затем он открывается в любом текстовом редакторе - лучше всего в самом же joe и, после соответствующего изучения, правится вручную.

В экранной документации синтаксис конфигурационного файла не описан, что мотивируется его простотой и понятностью. Это действительно почти так - смысл практически всех настроек можно понять из контекста (и комментариев).

Файл joerc разбит на четыре секции. Первая - это глобальные опции редактора, большая часть которых может быть задана также параметрами командной строки. Все они - односложные и имеют вид -имя_опции (установить данную опцию) или --имя_опции (отменить ее). Опция является установленной (или, напротив, отмененной), если ею начинается строка (первая колонка, в терминологии программы - это относится и ко всем остальным секциям .joerc). Если строка начинается с пробела или табуляции, дальнейшее ее содержание рассматривается как комментарий и не учитывается. Комментарием является и все, отделенное пробелом от имени опции.

Описание всех опций заняло бы слишком много места, поэтому обращу внимание только на некоторые ключевые моменты. Обязательно следует включить (то есть удалить пробел в начале строки, если он имеет место быть) опцию

-asis

Это необходимо для правильного отображения символов кириллицы - иначе они будут показаны латинской транслитерацией.

Полезным представляется также установка опций:

-lightoff

обеспечивающей выключение подсветки выделенного блока после его перемещения или копирования, - иначе выделение это будет постоянно маячить перед глазами;


-marking

дающей подсветку текста между началом выделяемого блока и текущей позицией курсора. Можно отменить также создание страховых копий или, напротив, определить место для их помещения, отличное от исходных файлов. Это достигается включением опций

-nobackups

или

-backpath path

соответственно.

Интересная возможность - задание количества строк и колонок (знаков в строке) на экране, отличное от определенных для текущего терминала (виртуальной консоли) в целом, что задается опциями

-lines # -columns #

где # - количество строк и знаков, соответственно.

В этой же секции настраивается вид статусной строки (вывод которой, впрочем, можно и отключить опцией -nosta). Он определяется двумя опциями -lmsg и -rmsg. Первая определяет компоненты, выводимые в левой части строки, вторая - в правой. В любой из них можно вывести индикацию режимов (забивки или вставки, переноса слов, автоотступов), имя файла и показатель его изменения, текущее положение курсора (в строках, колонках или знаках), и т.д. Первый знак левой части статусной строки - escape-последовательность, определяющая ее общий вид: инвертирование цветов, выделение подчеркнутым или полужирным начертанием, мерцание.

Например, строка вида

-lmsg \i%k%T%W%I%X %n %m%R %M

указывает, что в левой части статусной строки в инвертированном виде (черным по белому, \i) должны быть выведены

префиксные ключи (%k), маркирующие включение режимов вставки/замены (%T), переноса слов (%W), автоотступа (%I), прямоугольного выделения (%X);

имя редактируемого файла (%n);

указание на модификацию файла (%m) и на режим "только для чтения" (%R);

индикатор включения протоколирования макросов (%M).

Строка же вида

-rmsg Row %r Col %c %o %O %u

выводит в правой части статусной линии номер текущей строки (Row %r) и колонки (Col %c) файла, смещение от начала в байтах (в десятичной, %o, и шестнадцатеричной, %O, формах, и системное время в 24-часовом формате (%u).

Возможен вывод и иной информации, как то:

системного времени в 12-часовом формате (%t);



индикации измененного файла символом *;

ASCII-кода символа под курсором в десятичной (%a) или шестнадцатеричной (%A) форме;

процента просмотра файла до позиции курсора (%p);

общего количества строк в файле (%l);

индикации запуска встроенной оболочки (%S).

Кроме того, внешний вид статусной строки можно изменить, придав ему, вместо или помимо инверсии, атрибуты подчеркивания (\u), полужирного начертания (\b), мерцания (\f).

Вторая секция конфигурационного файла - это локальные опции, которые можно определить отдельно для файлов различных типов. Для этого в ее составе создаются субсекции вида

* все файлы *.html документы HTML *.c программы на C *rc конфигурационные файлы

и так далее. Напомню здесь, что знак маски (*) должен обязательно начинаться с начала строки, то есть занимать первую колонку.

Для каждой субсекции можно независимо задать такие параметры, как перенос слов (или его отключение), автоматический отступ, величину табуляции и т.д., а также, что интересно, назначить собственную раскладку клавиатуры, отличную от определенной для консоли в целом. Кроме того, с файлами любого типа можно связать макросы, выполняемые при их загрузке или записи.

Третья секция описывает вид экранов помощи, выводимых клавишной комбинацией Control+K - H. Экраны эти могут быть изменены как с позиций внешнего вида (инверсия цветов, выделение или подчеркивание и т.д.), так и по существу. В частности, здесь можно задать специальные экраны помощи для собственных макрокоманд. Более того, редактированием этой секции можно выводить и подсказки на русском (или каком-либо еще) языке. В частности, для макросов ввода тэгов html, описанных в одном из предыдущих разделов, можно создать экран помощи вида:

{HTML \i Help Screen turn off with ^KH more help with ESC . (^[.) \i \i\uGeneral\u \uBody Text\u \uList&Table\u \u \i \i^KF1 Blank F5 P F7 Pre ^KF8 Div ^KF2 UL ^KF3 OL ^KF4 LI F10 Href ^KF9 \i \iF1-F4 H1-H4 F6 Br F8 Strong F9 Em ^KF5 Tab ^KF6 TR ^KF7 TD ^KF10 Name }

Каждый такой экран заключается в фигурные скобки, предваряется собственным идентификатором (в примере - HTML), ему придаются атрибуты внешнего вида (в примере - инвертирование рамки, \i), задается строка подсказки, после чего следует просто перечисление клавишных комбинаций и их описание.



Четвертая секция - разного рода ключевые последовательности, или связки (key bindings), в том числе и макрокоманды. Они могут быть определены отдельно для всех окон (субсекция :windows, опять же начиная с первой колонки), окна редактируемого текста (субсекция :main), и так далее.

Внимательное рассмотрение секции показывает, что все описанные выше (и перечисленные в приложении) клавишные комбинации joe представляют собой макрокоманды, именно здесь и определенные. Из чего следует два вывода.

Первый - возможность переопределения клавиатурных комбинаций, назначенных для штатных команд joe по умолчанию. Например, если вам не нравится, что пролистывание экрана осуществляется комбинациями Control+U (назад) и Control+V (вперед), можно присвоить им иные значения (из числа свободных, разумеется).

Второй вывод - штатные команды joe могут быть (почти) неограниченно наращены собственными макрокомандами. Для чего достаточно их запротоколировать и поместить (напомню, посредством Escape - D) в соответствующее место четвертой секции (скорее всего, в раздел :windows или :main) файла ~/joerc. Более того, здесь же им можно присвоить и членораздельные имена (вместо данных по умолчанию Macro 1, Macro 2 и т.д.), во-первых, и изменить закрепленные клавишные комбинации (по умолчанию - Control+K - 0 и т.д.) - во-вторых. То есть полностью индивидуализировать редактор, не прибегая ни к каким сильнодействующим средствам.

Пользовательские макросы следует помещать в одну из субсекций - :window или :main. В последней, кроме этого, целесообразно отредактировать имеющиеся там по умолчанию макросы проверки орфографии для работы с русским словарем. По умолчанию эти макросы описываются строками вида:

:def spellfile
:def spellword

для спеллинга всего текста и отдельных слов, соответственно. Они просто описывают параметры вызова внешней программы проверки орфографии (по умолчанию - ispell). И подключение русского словаря при этом, разумеется, не предусмотрено. Чтобы осуществить это, следует просто добавить к обеим строкам после вызова исполнимой команды ispell опцию -d russian, в результате чего строки эти примут вид:

:def spellfile filt,"cat >ispell.tmp;ispell -d russian ispell.tmp \ </dev/tty >/dev/tty;cat ispell.tmp;/bin/rm ispell.tmp",rtn,retype :def spellword psh,nextword,markk,prevword,markb,filt,"cat \
>ispell.tmp;ispell -d russian ispell.tmp </dev/tty >/dev/tty;tr -d \<ispell.tmp '\\012';/bin/rm ispell.tmp",rtn,retype,nextword

Символы обратного слэша в конце строк означают только то, что каждая строка на самом деле не должна прерываться - вносить их в тело макроса не следует (нужно только позаботиться, чтобы опция переноса слов в редакторе была отключена).


Настройки редактора


Ибо настало время обратиться к настройкам quanta. Черновая настройка редактора выполняется через одноименный пункт главного меню - подпункт Настроить Quanta, вызывающий конфигурационную ,панель с несколькими пунктами (рис. 26). Содержание их вполне очевидно, и задерживаться на нем я не буду.


Рис. 26. Общие настройки редактора quanta - вещь достаточно очевидная для умеющих читать (даже только по русски)

Отдельный момент настройки - подпункт Настроить редактор в том же пункте Настройка главного меню. Здесь также все достаточно ясно, если внимательно ознакомиться с пунктами соответствующей панели (рис. 27).


Рис. 27. Настройка редактора - также дело не очень сложное

Помнится, я обещал, что quanta позволяет автоматизировать ввод тегов, в том числе и тех, которые не предусмотрены штатными средствами - через меню или пользовательские панели. Однако внимательный зритель ни в одно из пунктов меню Настройка не обнаружит ни определений собственных тегов, ни средств автоматизации их расстановки. Не просматривается и удобного способа для задания элементов xml-разметки. Что же делать?

Оказывается, просто-напросто обратиться к пункту главного меню, именуемому Панели инструментов - именно таким образом настраивается все то, о чем идет речь.

В указанном пункте обнаруживаются такие варианты:

Загрузить - вызов одной из уже существующих пользовательских панелей, глобальных, то есть доступных для всех пользователей данной системы (их местонахождение - подкаталог share/apps/quanta/toolbars/ в корневой директории KDE, например, /opt/kde или /usr/local/kde), локальных, принадлежащих данному пользователю (имеющих местопребыванием $HOME/.kde/share/apps/quanta/toolbars/) или панелей проекта (помещаемых в каталог /path_to_proj/toolbars); заметим, что по умолчанию загружены все доступные панели из числа глобальных, а локальных панелей и панелей проекта пока в природе не существует;

Сохранить - сохранение новосозданной панели в качестве локальной или панели проекта; очевидно, что сохранять и изменять глобальные панели обычный пользователь не может;


Добавить пользовательскую панель - это именно то, чем мы вскоре займемся;

Удалить пользовательскую панель - это не удаление как таковое, а лишь дезактивация одной из загруженных (по умолчанию или через подпункт Загрузить) панелей;

Переименовать пользовательскую панель инстументов и Отправить панель инструментов по E-Mail - в комментариях не нуждаются;

Загрузить панель инстументов - скачивание из интернета (с узла quanta.kdewebdev.org) какой-либо ранее разработанной панели.

Очевидно, что наши действия должны начинаться с пункта Добавить пользовательскую панель. В ответ на что нам будет предложено задать имя панели (по умолчанию - User_0). После этого в число закладок добавится новая - с соответствующим именем, а соответствующая ей панель инстументов будет пуста - остается лишь наполнить ее содержимым.

Для этого нам придется отправиться в пункт Настройки главного меню и выбрать там подпункт Настроить панели инструментов. После этого взору предстает следующее окно (рис. 28).



Рис. 28. Настройка пользовательских панелей инструментов

Вверху окна - выпадающее меню, в котором перечислены имена всех активных (то есть загруженных в данный момент) панелей. В левом "окошке" - перечень доступных действий; повторяю, они соответствуют кнопкам загруженных пользовательских панелей (и подпунктам Теги главного меню). А правое "окошко" содержит действия, кнопки для которых включены в текущую пользовательскую панель.

Так что для наполнения новообразованной панели нужно выбрать ее имя в выпадающем меню - очевидно, что правое "окошко" при этом окажется пустым, и в него просто перетаскиваются пиктограммы для требуемых действий.

Ясно, что таким образом можно только перекомпоновать кнопки тегов, которые и так были ранее доступны. А где же обещанная возможность создавать теги собственные? Да рядом, в подпункте Настроить действия пункта Настройка главного меню. В появившемся диалоговом окне выбирается тип действия кнопки (кроме тега, к кнопке пользовательской панели можно привязать также сценарий и просто текст), задать ее название и всплывающую подсказку, а также ввести собственно тег (при необходимости - также и закрывающий), как это показано на рис. 29.


Для тегов, допускающих использование атрибутов и их значений, можно поставить переключатель запуска диалога, то есть создать диалоговую кнопку.



Рис. 29. Задаем атрибуты вновь создаваемой кнопки новой пользовательской панели

Вновь созданной кнопке будет присвоен некий умолчальный значок. Который несложно изменить - через пункты меню Настройка - > Настроить панели инструментов.

Заполнив новую панель инстументов кнопками для требуемых тегов, остается только сохранить ее либо как локальную, либо как панель проекта. Первый вариант понятен - нужно только записать файл панели (а он имеет вид name.toolbar.tgz, то есть представляет собой сжатый архив) в нужный подкаталог. Для html-панелей это будет $HOME/.kde/share/apps/quanta/toolbars/html. А вот зачем нужны собственные панели в отдельном проекте?

Ответ не сложен. Представьте себе, что вы ведете два сайта, один - в стиле pure html, другой же - на базе xml-технологий. Очевидно, что в том и ином случае потребуется совершенно разные наборы тегов (а теги XML создавать в quanta так же легко, как и обычные html-теги), объединение которых в общих пользовательских панелях приведет только к их загромождению. Тут то и стоит вспомнить о возможности создания собственного комплекта панелей для каждого проекта.

Все это, конечно, очень благородно, - скажете вы мне. Но ведь предлагалось использовать quanta не просто для разметки уже существующего текста. а для его набора - с автоматическим вводом тегов в процессе оного. А разве это верх удобства - отрывать при наборе руки от клавиш и тянуться к мыши для того, чтобы ввести тег нажатием на кнопку инструментальной панели? Отнюдь - скажет любой пользователь с навыками ремингтониста (это - мужской род от слова "машинстка", на заре машинописи работа эта считалась столь тяжелой, что ее исполняли исключительно мужчины). И будет бесусловно прав. Так что пора исполнить обещание и рассказать, как же вводить теги исключительно с клавиатуры, без всякого участия мышей и прочих грызунов.



А сделать это можно соответствующей настройкой "горячих" клавиш. Для чего опять отправляемся в меню Настройка -> Настроить действия, обращая внимание на блок Комбинации соответствующего диалогового окна (см. рис. 10). В блоке этом мы видим два переключателя - Нет, отмеченный по умолчанию, и Другой. Его-то и следует отметить, что вызовет появление еще одного окошка (рис. 30). Тут достаточно нажать ту клавишу (или комбинацию оных), к которой хотелось бы привязать ввод данного тега - и в дальнейшем она будет выступать в качестве "горячей", действие которой эквивалентно нажатию экранной кнопки на пользовательской панели.



Рис. 30. Привязка клавишных комбинаций

Теперь остается самая малось - обеспечит загрузку новосозданной пользовательской панели при старте quanta, само собой это не произойдет. Тут потребуются некоторые действия руками, хотя и несложные. Во-первых, в домашнем каталоге должен присутствовать файл descrition.rc - он размещается в подкаталоге $HOME/.kde/share/apps/quanta/dtep, соответствующем нужному DTP (например, html-transitional. Поще всего скопировать его прототип из opt/kde/share/apps/quanta/dtep/html-transitional и чуть отредактировать. А именно - отыскать в нем (в секции [Toolbars]) строку вида

Names = standard, style, tables, lists, forms, other

и дописать туда имя файла новой пользовательской панели - через запятую и пробел, без суффиксов toolbar.tgz, например - mybar.

Я привел лишь простой рецепт создания собственной пользовательской панели и обеспечения ее загрузки, без объяснения механизма действий. Для более глубого понимания оного можно ознакомиться с документацией по редактору quanta, вызываемой через меню Справка -> Руководство "Quanta", в разделах 5. Расширение Quanta Plus. Здесь же описываются и принципы работы с DTP, знание которых необходимо для решения более сложных задач - полноценного использования XML, стилевых таблиц, php-сценариев и прочего высшего web-пилотажа.


Несколько слов о ee


Редактор ee (Easy Editor) - прост и незатейлив, и именно поэтому рекомендуется как базовый во FreeBSD. Он входит в состав базовой системы (Distributions) и, собственно, является там чуть не единственным представителем этого семейства. Не считая, конечно vim, но в базовой системе он замаскирован под классический vi, и потому а) функционально ограничен и б) поначалу не особенно легок в использовании. Так что на первом этапе освоения FreeBSD (и DragonFlyBSD) ee может быть столь же естественным выбором, как и nano для начинающего пользователя Linux.

Запускается ee одноименной командой

$ ee file

где file (необязательный аргумент) - имя файла, подлежащего редактированию. После этого открываются два окна редактора. В нижнем - редактируемый текст (если файла с указанным именем не существует, или ee запущен без аргумента - окно это остается пустым), в верхнем - краткая, но практически исчерпывающая справка по использованию программы.

Навигация по тексту осуществляется или обычным способом - клавишами управления курсора, PageUp, PageDown, Home, End и т.д., либо - специфичными для ee управляющими (или командными) комбинациями клавиши Control с какой-либо из литерных. Так, комбинация Control+f (от forward) перемещает курсор на один символ вправо (т.е. вперед), Control+b (от backward) - на один символ влево (т.е. назад), и так далее. Причем возможности управляющих комбинаций шире - например, они позволяют перейти к следующему слову (Control+z), перейти в начало (Control+t) или конец (Control+u) экрана.

Аналогично и редактирование текста можно выполнять двояким образом: посредством клавиш редактирования (Backspace, Delete) или такими же управляющими комбинациями. Причем последний способ, как и в случае навигации, - более эффективен, позволяя удалить не только отдельный символ (Control+d), но и целиком слово (Control+w) или строку (Control+k).

Редактор ee не является истинно командным, и основные действия в нем осуществляются через меню, вызываемое нажатием клавиши Escape.
Пункты главного меню - следующие:

+------------------------+ | a) выйти из редактора | | b) подсказка | | c) операции с файлами | | d) обновить экран | | e) параметры | | f) поиск | | g) разное | +------------------------+

Смысл всех пунктов вполне понятен, и пользователь легко освоит их эмпирическим методом (тем более, что многого осваивать и не требуется). Скажу только, что при выходе из редактора (пункт a)) выдается запрос на сохранение изменений в файле, буде таковые производились:

+------------------------+ | Файл изменён! | | | | a) сохранить и выйти | | b) не сохранять | | | | для отмены нажмите Esc | +------------------------+

И еще следует заметить, что вывод подсказок и сообщений на русском языке (как в приведенном примере) происходит только при правильной локализации, т.н. установке русской локали (locale).


О web-инструментарии вообще


Появление web и html можно сравнить с изобретением полковника Кольта, уравнявшего, вопреки воле Господа, людей сильных и слабых посредством широко известного из литературы и кино инструмента. Если в доинтернетовскую эру автору для публикации своих произведений требовалась мощная производственная база (или - контакт с лицами и организациями, таковой располагающими, сиречь издательствами), то с появлением web все оказалось в его руках - Всемирная паутина предоставляет неограниченные возможности для творческого самовыражения. Единственное условие - умение представить свое произведение в одной из форм, для этой самой паутины приемлемых. А формой, наиболее универсальной из приемлемых, является самая тривиальная html-страница - структурированный текст, размеченный посредством соответствующих тегов.

Разметка html-страницы - занятие не сложное, однако расставлять теги все равно нужно. И потому не замедлил появиться инструментарий для выполнения этого процесса. В том числе - и ориентированный на открытые и свободные POSIX-совместимые платформы, из каковых наибольшее распространение получил Linux (и, в меньшей степени, FreeBSD). Опять же обращаясь к собственным воспоминаниям, замечу, что именно подготовка web-материалов оказалась той областью, в которой мне впервые (в далеком уже 1998 году) удалось применить мощь POSIX-систем в мирных, то есть настольно-производственных, целях.

К слову сказать - работа с html-материалами представляет интерес отнюдь не только для профессиональных web-дизайнеров, web-мастеров и прочих лиц, по долгу службы связанных с Интернет-технологиями. Ибо это - чуть ли не единственный (за исключением plain text, конечно) формат, почти однозначно воспринимаемый на всех аппаратных платформах, во всех операционных системах, в любом национально-языковом окружении (в том числе даже и русском, с его многочисленными кодировками Великого и Могучего). И, в отличие от чистого текста, позволяющий представлять материал в структурированном и визуально оформленном виде.


Изначально существовало два направления в технологии подготовки web-страниц - визуальное их редактирование и редактирование html-кода. В первом случае порядок действий точно такой же, как и при подготовке для печати обычных текстов в программах, именуемых по русски обычно текстовыми процессорами, вроде всем известного MS Word (на самом деле text processor - это совершенно другая вещь, а программы этого класса в оригинале именуются word processor, но это тема для отдельного разговора). Что легко и просто, однако далеко не всегда способно дать результат, адекватный задуманному (а при отсутствии специфического опыта - подчас прямо противоположный). И потому о визуальных редакторах речи здесь не будет.

Да, еще: все сказанное ниже относится к работе с преимущественно текстовыми web-материалами. Подготовка web-графики - тема совершенно отдельная, и здесь почти не затрагивается.

В качестве же редактора html-кода можно использовать обычный текстовый редактор. Каковых в свободном исполнении, как известно, существуют многие множества. Причем тут опять же возможно два подхода - ввод тегов в процессе набора материала или предварительная его подготовка в формате plain text с последующей его разметкой. И то, и другое в принципе не влечет за собой никаких сложностей, но весьма занудно, так как сводится к многократному повторению рутинных действий. И потому возникает естественное желание как-то автоматизировать этот процесс (ибо, как неоднократно подчеркивалось, приверженность смертному греху лености - неотъемлемый атрибут истинного POSIX'ивиста).

Напрашивающееся решение автоматизации ввода тегов в уже существующий текстовый материал - использование shell-скриптинга. Благо среди классических Unix-утилит нетрудно отыскать соответствующие средства, например, потоковый (неинтерактивный) текстовый редактор sed. В сочетании с утилитами поиска файлов и последовательностей символов в оных (find и grep, соответственно), он, благодаря штатным средствам POSIX-систем (механизмам конвейеризации команд и перенаправления их ввода/вывода), способен решить большинство задач html-разметки (и не только ее).


Дополнительный плюс этого подхода - возможность пакетной разметки большого количества web-страниц одновременно.

Есть, однако, и минусы. Сочинение shell-скриптов вообще требует некоторых навыков, а в данном случае необходимо еще и знание особенностей собственно утилиты sed (или - языка awk, также пригодного к выполнению этой задачи). Требуются и некоторые чисто программистские навыки - представление об операторах, например. Все это, конечно, дело наживное - однако, по моему скромному мнению, временные затраты на сочинение сценариев html-разметки оправданы только в том случае, если уже имеется достаточно большой объем чисто текстовых материалов, которые необходимо претворить в web-страницы. При сочинении же их с нуля более целесообразно автоматически вводить теги одновременно с набором текста.

Благо и тут свободные программы - в лице обычных текстовых редакторов, - окажутся небесполезными. Практически любой представитель этого семейства, функциональность которого выходит за элементарные рамки (а за точку элементарности можно принять штатный ee из FreeBSD и nano, входящий в большинство Linux-дистрибутивов), располагает собственным макроязыком программирования. Остается только сочинить соответствующие макросы и привязать их к "горячим" клавишам, чтобы в дальнейшем в ответ на нажатие, скажем, клавиши F1 получать заголовок 1-го уровня, клавишей F4 оформлять параграфы (тег ) и так далее. Если же и макросы сочинять лениво - в распоряжении пользователя всех более-менее "продвинутых" редакторов имеется возможность протоколирования собственных действий с оформлением результата в виде макрокоманд. В можно найти примеры того, как легким движением руки универсальные текстовые редакторы joe и nedit превращаются в специализированные инструменты для создания web-страниц. А для таких гигантов текстового редактирования, как vim или emacs дополнения для html-разметки придуманы давным-давно - нужно только их поискать на соответствующих сайтах (для начала - на http://www.vim.org и http://www.gnu.org/software/emacs, соответственно).



Особого внимания в качестве web-инструмента заслуживает kate - наиболее мощный из штатных текстовых редакторов KDE. Как и в файловом менеджере konqueror, описанном в предыдущей интермедии, парадигма его - интеграция эпонимического средства (в данном случае - текстового редактора) со средствами визуализации файловых операций и полноценным эмулятором терминала, к коим добавлен мощный инструмент для поиска файлов. Есть в kate и штатные способы полуавтоматического ввода тегов HTML (и даже XML, с проверкой валидности последних), и средства ведения проектов, и многое другое. Правда, расширение штатных возможностей этого редактора - задача нетривиальная, требующая уже всамделишнего умения программировать. Однако и наличных модулей расширения для kate (объединяемых в комплекс KPart) хватает для решения многих и многих задач.

Такой адаптированный текстовый редактор - прекрасный инструмент для работы с отдельными web-страницами и небольшими их наборами, типа домашних страниц. Однако плох тот "хомяк", который не мечтает стать полноценным контент-сайтом. А при работе с таковым хочется уже большего - средств ведения проектов и поддержания их целостности, как минимум.

Конечно, и эта проблема решаема штатными POSIX-средствами. Все уважающие себя текстовые редакторы POSIX-мира позволяют запускать внутри себя команды оболочки и командные конструкции, в том числе и пользовательские сценарии. И ничто не мешает сочинить набор скриптов для открытия группы объединенных в проект файлов, проверки целостности внутренних ссылок, предварительного просмотра в распространенных браузерах и прочих функций, ожидаемых от средств ведения проектов. Кроме одной мысли - а не изобретаем ли мы тем самым велосипед? И не сделал ли это кто-нибудь до нас?

Поскольку пользователь POSIX-систем стоит на плечах гигантов, ответ, разумеется, будет положительным. Остается только такие средства отыскать. К счастью (или - к сожалению?) полноценных редакторов html-кода для свободных платформ не так и много - всего три.Это bluefish и screem, базирующиеся на библиотеке Gtk, и Quanta Plus, предназначенная для работы в среде KDE (и, соответственно, использующая библиотеку Qt). Именно о последней и пойдет речь далее в этой заметке.


Обзор возможностей


Текстовый редактор joe - типичный представитель консольных редакторов командного стиля, то есть ориентированных не на действие через меню, а на управление с помощью прямых директив. Название его можно перевести примерно как "редактор дядюшки Джо". Он создан Джозефом Алленом (Joseph H. Allen) при участии Ларри Форда (Larry Foard) и Гари Грея (Gary Gray). Это - открытая и бесплатная программа, доступная в исходниках на сайте проекта. Она реализована для всех, насколько я знаю, POSIX-совместимых систем. А некоторые конкретные версии были собраны для Windows всякого рода и даже для DOS.

Запускается joe одноименной командой, можно - с именем файла, предназначенного для редактирования. В случае, если этого имени в природе не имеется, создается новый файл. Кроме этого, при запуске joe можно использовать ряд опций командной строки. Представление о них дает чтение страниц экранной документации (man joe).

Сразу после запуска joe выглядит весьма непрезентабельно: черный экран с белым текстом - и все. Что делать дальше - остается пока неясным. Единственно, строка заголовка в верхней части экрана гласит, что с помощью комбинации клавиш Control+K - H можно вывести на экран систему помощи. И далее пролистывать ее с помощью Escape - . (точка) - вперед или Escape - , (запятая) - назад.

Так вот, внимательное знакомство с системой помощи дает представление о возможностях редактора. Каковые неожиданно оказываются весьма богатыми.

Думаю, понятно, что текстовый редактор позволяет вводить текст (в том числе и кириллический) и обеспечивает навигацию по нему, а также редактирование. Последняя осуществляется двояко: либо с помощью собственных клавишных комбинаций (как правило, это Control+литера), о чем подробнее - в следующем разделе, либо - стандартных клавиш управления курсором (стрелок, PageUp, PageDown, End, Home). При этом клавиши эти введут себя обычным (с точки зрения пользователя DOS/Windows) образом, что отнюдь не само собой разумеющееся для консольных Unix-редакторов).


Вообще, следует заметить, что основным средством навигации по тексту в joe являются именно собственные управляющие последовательности, а не клавиши управления курсором. Во-первых, при наличии некоторого навыка, они обеспечивают большую скорость работы за счет того, что не требуется перемещения пальцев за пределы основной клавиатуры (поверьте, это действительно быстрее!). Во-вторых, как неоднократно подчеркивалось и ранее, команды joe, вызываемые клавишными комбинациями, функционируют абсолютно одинаково на терминалах любых типов.

Мышь в joe поддерживается стандартным для Unix-консоли образом. То есть она выступает не как указательное устройство, а как средство выделения и копирования текстовых блоков. Это относится как к текстовой консоли, так и к эмуляторам терминалов графического режима.

Разумеется, в соответствие со своим званием joe позволяет и редактирование текстов, то есть: выделение блоков и отдельных знаков, их копирование, перемещение и удаление, форматирование абзацев (центрирование, лево- и правостороннее выравнивание и т.д.), вставку существующих файлов в текущий документ и запись выделенных фрагментов в виде отдельных файлов.

Редактор joe имеет функцию многоуровневой отмены и возврата отмененных операций. Встроенной проверки орфографии нет, однако можно подключить внешнюю программу (такую, как ispell), в том числе и для русскоязычных текстов. Имеются достаточно развитые средства поиска и замены, в том числе с использованием шаблонов и регулярных выражений. Есть возможность создания закладок (Bookmarcs) и перехода к ним, что необходимо при редактировании длинных структурированных документов.

В joe имитируется многооконный режим: поле текущего документа может быть разбито пополам, и далее каждое из них также может делиться сколь угодно дробно (правда, только по горизонтали). Обеспечена также одновременная работа со многими документами, каждый из которых может быть выведен в оконном или полноэкранном виде. Количество одновременно открытых файлов не ограничено ничем, даже, по некоторым сведениям, системной памятью - joe позволяет работать с документами, размер которых превышает объем ВСЕЙ доступной (то есть физической и виртуальной) памяти.


Правда, проверить это на современных машинах несколько затруднительно...

В joe поддерживается собственный макроязык с достаточно прозрачным синтаксисом. Кроме того, имеется режим протоколирования макросов, что позволяет быстро наращивать его возможности.

И вообще, joe - очень настраиваемый редактор. Во-первых, имеется система интерактивной настройки ряда параметров, таких как перенос слов, абзацный отступ и т.д. Правда, установки эти действуют только в текущем сеансе. Для перманентных изменений необходимо редактирование конфигурационного файла. Однако здесь, учитывая возможность встраивания макрокоманд, возможности настроек становятся поистине безграничными.

И наконец, что немаловажно в наших условиях, joe корректно работает с кириллицей. При правильно русифицированной консоли не возникает никаких проблем ни с выводом, ни с вводом символов кириллицы (в том числе, в последних версиях, и с кодировке UTF8). Более того, все клавишные комбинации работают и при латинской, и при русской раскладке клавиатуры. Правда, в последнем случае обычно требуется дополнительное нажатие управляющей клавиши.

Иными словами, joe - вполне развитый и полнофункциональный текстовый редактор общего назначения. Он в равной мере пригоден для эпизодической работы по написанию скриптов, правке конфигурационных файлов и т.д., и для систематического использования при создании длинных структурированных текстов нарративного характера. А наличие языка макрокоманд допускает эффективно применять его и в специальных целях - для разметки html-страниц, верстки документов в TeX, не говоря уже о собственно программировании.


Представление героини


Итак, Quanta Plus - программа, позиционируемая как универсальное средство web-разработчика. Это - относительно недавнее достижение свободной софтверной мысли: первые ее версии появились в начале 2000 года. В числе разработчиков ее - норвежец Эрик Лаффон (Eric Laffoon) и два наших соотечественника, хотя и бывших - с Украины: Дмитрий Поплавский и Александр Яковлев (рис. 20).


Рис. 20. Приятно, что в числе разработчиков quanta есть и наши соотечественники, хотя и бывшие

Некоторое время quanta развивалась как самостоятельное приложение, затем в виде отдельного пакета была включена в штатный комплект KDE. Ныне (начиная с KDE версии 3.3.1) quanta - главная составляющая KDE-пакета kdewebdev, включающего также еще несколько утилит этого профиля (о некоторых я расскажу в конце этой интермедии).

Об установке quanta много говорить не стоит - ее можно инсталлировать штатными средствами конкретного дистрибутива вместе со всей средой KDE или отдельными ее компонентами. Нет препятствий и для ручной сборки пакета из исходников - предварительно нужно только озаботиться установкой kdebase и kdelibs (прочие зависимости - опциональны, и будут выведены по завершении исполнения конфигурационного сценария).

Запуск quanta также элементарно прост и может быть выполнен а) из K-меню (через пункты Разработка -> Среда web-разработки (Quanta Plus), из строки мини-терминала (пункт K-меню Выполнить программу) или в) просто из терминального окна (в двух последних случаях нужно просто набрать в командной строке quanta). Иконку для запуска quanta можно вынести на рабочий стол или в панель задач KDE. Можно и просто открыть html-файл в редакторе, щелкнув в konqueror'е на нем правой клавишей, выбрав из контекстного меню пункт Открыть в - подпункт Quanta Plus будет наличествовать по умолчанию.

По своему запуску quanta обеспечивает обычные для программ этого класса возможности набора и редактирования html-кода: автоматический ввод основных тегов и их атрибутов, подсветку синтаксиса, предварительный просмотр web-страницы и так далее. Весьма развиты просто средства обработки текстов - поиск и замена (в том числе с использованием регулярных выражений), проверки орфографии. Из web-специфичных "продвинутых" возможностей стоит отметить, во-первых, уже упоминавшиеся средства управления проектами (удачно дополняемые интегрированным файловым менеджером, представляющим собой облегченный вариант konqueror) и, особенно, визуальный редактор, позволяющий выполнять html-разметку методами, привычными по работе с текстовыми процессорами.

Допускает quanta также и весьма изощренные приемы работы - с языком разметки XML и стилевыми таблицами, сценариями PHP и многим другим, необходимым для профессионального web-мастера. Однако в этой заметке я сконцентрирую свое внимание на то, что этот редактор дает народу (то есть простому пользователю), и как его настроить оптимальным образом для набора html-документов.



Работа с проектами


Поддержка проектов - один из необходимых атрибутов развитого html-редактора: как я уже говорил, все прочие его функции вполне можно смоделировать в редакторе обычном. И quanta такую поддержку обеспечивает - хотя и не в том объеме, как этого бы хотелось.

Для создания проекта следует обратиться с одноименному пункту главного меню - к его подпункту Новый проект, вызывающему своего рода мастер проекта. Первой из диалоговых панелей (рис. 24) задается имя проекта (оно автоматически присваивается его эпонимическому файлу - pojetc_name.webprj, сервер с его протоколом (например, ftp, можно, разумеется, создать и проект на локальной машине, без подключения к сети), главный каталог и подкаталоги для шаблонов и пользовательских панелей (о которых речь пойдет дальше). В следующей панели, при необходимости, можно добавить в проект уже существующие файлы - все из данного каталога или по определенной маске (например, *.html).


Рис. 24. Создание проекта начинается с указания его имени, главного каталога и каталогов шаблонов и пользовательских панелей

Затем (рис. 25) автор может указать свое имя и адрес электронной почты, а также раз и навсегда определить DTD всех документов проекта и их кодировку (я, кажется, забыл отметить, что quanta прекрасно работает со всеми кодировками русского языка, включая UTF8, но исключая cp866).


Рис. 6. Следующий шаг - задание общего DTD и кодировки для документов проекта

Главное, что дает создание проекта - это возможность определить для него шаблоны и пользовательские панели инструментов. Касаться шаблонов я здесь не буду - это, как уже было сказано, тема домашнего задания. А о пользовательских панелях речь пойдет в скором времени.



Система помощи


Ознакомиться практически со всеми возможностями редактора joe можно посредством его системы помощи. Как уже говорилось, она выводится на экран нажатием комбинации клавиш Control+K-H и насчитывает семь секций, каждая из которых занимает собственный экран, перемещение между которыми осуществляется комбинациями клавиш Meta+. (вперед) и Meta+, (назад).

Первая секция, Basic, описывает действия наиболее общего плана: перемещения курсора (субсекция CURSOR), переходы по тексту (субсекция GO TO), операции с текстовыми блоками (субсекция BLOCK), команды удаления символов и текстовых фрагментов (субсекция DELETE), команды поиска, проверки орфографии, форматирования (субсекции SEARCH, SPELL, MISC), операции с файлами (субсекция FILE), а также выход из редактора.

Вторая секция посвящена описанию манипуляций с окнами - расщеплению (split) экрана, скрытию и показу открытых окон, переходу между окнами, изменению их размера.

В третьей секции собрано описание расширенных возможностей для редактирования текстов, как то:

работа по протоколированию, записи и воспроизведению макросов (субсекция MACROS);

команды для прокрутки текста (субсекция SCROLL);

команды для взаимодействия с оболочкой (субсекция SHELL);

средства установки закладок, наращиваемого поиска, ввода спецсимволов (секции BOOKMARKS, I-SEARCH, QUOTE) и так далее.

Четвертая секция - расширенные возможности для программистов (команды перехода к регулярным выражениям, компилирования и отладки). В пятой секции дано описание сложных регулярных выражений. И, наконец, шестая секция - операции с командной строкой встроенной в редактор командной оболочки.

Таковы возможности справочной системы joe по умолчанию. Как будет показано ниже, пользователь может не только изменять имеющиеся секции, но и создавать собственные, в любом количестве и для любых целей.

Если мне удалось убедить читателя, что joe - вещь стоящая, имеет смысл подробнее рассмотреть с его



Vi и Vim: введение в тему


Редактор vi (или какой-либо из его клонов) - непременный атрибут всех Unix-систем, и потому любой их пользователь должен иметь о нем представление, хотя для повседневной работы какой-либо иной редактор может оказаться более подходящим.

Поначалу vi может показаться порождением больного ума с садомазохистскими наклонностями. Однако достаточно осознать внутреннюю его логику - и начинаешь понимать, что более быстрого инструмента для обработки текста человеческий разум еще не придумал. А многочисленные возможности для его настройки обеспечивают должную функциональность такой обработки. Хотя, с другой стороны, создание нарративных текстов - не самая сильная его сторона. Однако к этому вопросу я еще вернусь.

Существует несколько редакторов, основанных на vi, включающих дополнительные возможности, но полностью совместимых с ним по системе базовых команд. И потому знание vi обеспечит возможность работы с любым из его клонов. Более того, если в некоей Unix-системе вместо vi используется какой-либо из редакторов-клонов, например, Vim или elvis, в каталоге /usr/bin

всегда будет представлен файл vi, являющийся жесткой или символической ссылкой на реальный исполнимый файл этого редактора. Поэтому vi или любой его аналог всегда может быть запущен командой

$ vi имя_файла

хотя реально при этом запускается, например, Vim. Тем более, что сам по себе vi в свободных POSIX-системах не используется из-за лицензионных соображений. Так что далее термины vi и Vim используются как синонимы, но везде имеется в виду Vim (Vi Improved).

Редактор Vim может быть запущен из командной строки оболочки с именем файла в качестве аргумента или без такового. В первом случае открывается файл, если он существует, или создается новый - в текущем каталоге, или в каталоге, определенном в пути к нему. Например, команда

$ vim ~/mytext/newtext.txt

создаст новый текстовый файл в подкаталоге ~/mytetxt домашнего каталога пользователя. Конечно, при этом каталог ~/mytetxt должен уже существовать, иначе при записи файла последует сообщение об ошибке.


Команда vim без имени файла откроет редактор Vim и выведет заставку следующего содержания:

VIM - Vi IMproved ~ ~ version 6.1b BETA ~ by Bram Moolenaar et al. ~ Vim is open source and freely distributable ~ ~ Help poor children in Uganda! ~ type :help iccf for information ~ ~ type :q to exit ~ type :help or for on-line help ~ type :help version6 for version info

которая сразу подсказывает направление дальнейших действий - можно либо немедленно начать работу (правда, как это сделать - я скажу чуть ниже), либо получить справку по использованию редактора.

Настоятельно рекомендую воспользоваться последней возможностью, так как работа в Vim окажется весьма непривычной для пользователя, привыкшего к текстовым редакторам DOS/Windows. В частности, попытка немедленно начать ввод текста успехом не увенчается. И потому следует сначала ознакомиться с режимами работы vi.

В vi существует три принципиально различных режима работы - командный, или визуальный (visual command mode), именуемый также нормальным, режим ввода (edit mode) и т.н. ex-режим, или режим построчного редактирования (ex mode или colon mode), который по-русски именуется еще и режимом ввода команд. Кроме того, в Vim (но не в классическом vi) дополнительно выделяется еще режим визуального выделения, или выбора.

Уже само по себе изобилие режимов способно запутать неподготовленного пользователя. А без четкого понимания различий между режимами никакая, даже самая элементарная, работа в vi попросту невозможна: широкое хождение имеют легенды о пользователях, полагающих единственным способом выхода из этого редактора перезапуск машины. И разнобой переводной русскоязычной терминологии только усугубляет дело. Однако, если рассмотреть эти режимы последовательно, все оказывается не так страшно.

Начнем с того режима, который включается по умолчанию при загрузке vi, почему далее я и буду именовать его нормальным - именно он обеспечивает быстроту перемещения по тексту и его обработки. К тому же из него осуществляется переход во все остальные режимы и возврат из них.


В нормальном режиме нажатия клавиш не приводят к вводу символов, а интерпретируются как внутренние команды навигации и редактирования, привязанные к различным алфавитно-цифровых или символьным клавишам и их комбинациям. Например, нажатие клавиши h вызывает перемещение курсора на один символ влево, клавиши l - на один символ вправо, k - на строку вверх, j - на строку вниз, и т.д.).

Предопределенные клавиши нормального режима чувствительны к регистру (и это имеет глубокий смысл, как будет показано чуть ниже) и последовательности нажатий. Так, повторное нажатие клавиши dd отнюдь не эквивалентно по действию двум ее одиночным нажатиям. Кроме того, они чувствительны и к раскладке клавиатуры. В частности, при включении кириллической раскладки никакие клавиши нормального режима при настройках по умолчанию просто не оказывают никакого действия. Впрочем, методы борьбы с этим существуют, о чем я расскажу в заключение раздела.

Естественно, создание текста в командном режиме невозможно. Для этого следует перейти во второй режим (будем называть его режимом ввода), для чего служат разнообразные команды (нормального режима!), например, a (от append) и i (от insert). Здесь нажатия клавиш приводят к вводу обычных буквенно-цифровых символов (после текущей позиции курсора в случае первой команды и перед ней - в случае второй), позволяя создавать новый текст или редактировать имеющийся. Хотя последнее более эффективно в командном режиме, возврат в который осуществляется клавишей Escape.

Для операций с документами (то есть файлами) предназначен третий режим, за которым резонно закрепить название командного. Он вызывается из нормального режима командой : (символ двоеточия). Вводимые после этого последовательности символов (или отдельные символы) воспринимаются уже как команды, не привязанные к фиксированным клавишам, но опознаваемые по своим именам (или их аббревиатурам). Здесь возможны следующие действия:

открытие существующего файла (:edit имя_файла, здесь и далее символ : указывает на принадлежность команды к командному режиму); если какой-либо файл перед этим уже загружен, он будет закрыт и замещен новым; если же изменения в нем не были сохранены - последует сообщение об ошибке;



вставка существующего файла в позицию курсора (:read имя_файла);

запись файла (:write), в том числе под другим именем (:write имя_файла);

выход из редактора (:quit), происходящий, если текущий файл не изменялся или был предварительно сохранен;

выход из редактора с предварительным сохранением измененного файла (:xit - от exit).

Одна из возможных причин путаницы нормального и командного режима - то, что в последнем допустимы любые аббревиатуры указанных команд, вплоть до односимвольных (каковые в обиходе, как правило, и используются): :e для открытия файла, :r -для его вставки, :w - для записи, :q и :x - для выхода. Однако это именно сокращения команд, а не клавиши, предопределенные для неких действий, как в нормальном режиме. Возможно совмещение команд командного режима, например, :wq - выход с предварительным сохранением измененного файла (что аналогично команде :x).

Команды отправляются на исполнение нажатием клавиши Enter, после чего происходит возврат в нормальный режим. Однако попытка, например, закрыть редактор без сохранения изменений в редактируемом документе (командой :q) или загрузить новый файл (командой :e), не сохранив предыдущий, вызовет сообщение об ошибке. Для принудительного выполнения таких действий команды :q и :e должны сопровождаться символом ! без пробела. Например, команда :q! закроет редактор vi, не сохранив изменений в текущем файле.

Действия командного режима частично дублируются в режиме нормальном. Так, в последнем для закрытия же файла (с предварительным сохранением изменений) используется комбинация Z-Z (двойное нажатие клавиши Z - регистр важен!), что является эквивалентом сочетания команд :wq командного режима.

Четвертый режим Vim назовем режимом выбора, поскольку именно для выбора фрагментов текста с целью последующего применения к ним команд нормального режима. Переход в него (как обычно, из нормального режима) осуществляется нажатием клавиш v или V. В обоих случаях нажатия клавиш управления курсором приводят не к его перемещению, а к выделению блока, в первом - начиная с текущего положения курсора в пределах строки, во втором - начиная с начала маркированной курсором строки.


Повторное нажатие тех же клавиш вызывает возврат в нормальный режим. Однако если нажать какую-либо клавишу, обеспечивающую действие в нормальном режиме, оно будет распространено на весь выделенный блок. Ну и после выполнения этого действия, естественно, происходит возврат в нормальный режим.

В современных версиях Vim предусмотрено нечто вроде индикации режимов - при включении режима ввода в нижней части экрана появляется надпись

-- INSERT --

при переходе в режим выбора - надпись

-- VISUAL --

Командный режим включается только по наборе символа : (предполагается, что пользователь этого не забудет сразу же), а нормальный режим, по замыслу разработчиков, на то и нормальный, что в индикации не нуждается. Впрочем, находясь в нормальном режиме, легко убедиться, что это он и есть. Для этого достаточно нажать клавишу Escape и услышать звуковой сигнал.

Такая система работы может показаться запутанной начинающему пользователю. Однако она имеет глубокое внутреннее обоснование. Редактор vi создавался изначально как кросс-платформенный, который обязан работать на любых типах реальных и виртуальных терминалов. И потому все действия в нем можно осуществить, не покидая основной, алфавитно-цифровой, части клавиатуры, без обращения к дополнительным клавишам - стрелкам управления курсором, Home, End, PageUp, PageDown, Insert, Delete, Backspace.

Это, с одной стороны, обеспечивает быстроту и эффективность работы (правда, только при наличии доведенных до автоматизма навыков). С другой стороны, внутренние команды навигации и редактирования всегда будут интерпретироваться идентично, независимо от типа терминала и его настроек.

Поскольку нормальный режим vi является не только основным, но и наиболее характерным для этого редактора (и - непривычным для пользователя!), имеет смысл ознаком иться с ним подробнее. Все изобилие команд vi (а их насчитывается много десятков) можно разделить на три группы:

команды навигации;

команды редактирования;

команды перехода (в режим ввода).



Команды навигации служат для перемещения курсора по тексту. В консольном режиме для этого могут быть использованы и обычные клавиши управления курсором (стрелки, PageUp/PageDown, Home/End). Однако уже в различных программах эмуляции терминала в Иксах их поведение неоднозначно (и зависит от настроек). К тому же внутренние команды дают больше возможностей для навигации по тексту, чем клавиши стандартных клавиатур.

Так, уже говорилось, что в vi существуют команды h и l, k и j, действие которых эквивалентно нажатиям клавиш Left и Right, Up и Down, соответственно. Но, кроме того, с помощью парных команд w и W можно переместиться вперед, соответственно, на т.н. "маленькое" слово (то есть отделенное пробелом или любым знаком препинания, символами - или +) и на "большое" (то есть обязательно отделенное пробелом) слово. Пара команд b и B выполняет аналогичное перемещение назад, а команды e и E перемещают курсор в конец следующего "маленького" и "большого" слова.

Вообще, для многих команд vi характерно наличие парных эквивалентов - в нижнем и верхнем регистрах одной клавиши (w и W, e и E); действие второй команды из пары как бы расширяет действие первой.

Возможны также перемещения в предыдущее (символ (, то есть открывающей скобки) и последующее (символ ), закрывающей скобки) предложения, в начало (H) и конец (L) экрана, в начало (0 - ноль) и конец ($) строки и т.д. - список навигационных команд приближается к 30. Иными словами, нажатием одной клавиши или, в крайнем случае, двухклавишной комбинации (Control+f - на следующую экранную страницы, Control+b - на предыдущую) можно переместиться в абсолютно любое заранее определенное место текущего документа.

В дополнение к этому, команды навигации vi могут использоваться с численными аргументами. Например, команда 5h переместит курсор на 5 символов влево (считая символ в позиции курсора), а команда 3k - на три строки вверх.

Далее, для навигации по тексту могут использоваться символы - (минус) для перемещения на одну строку вверх и + (плюс) для перемещения на одну строку вниз.


Особенно эффективны они в сочетании с численными аргументами: командой 7+ возможно перемещение на седьмую строку вперед, а командой 13- - на тринадцатую строку назад (в обоих случаях - включая строку в позиции курсора).

Команды редактирования предназначены для модификации существующего текста без перехода в режим ввода. Конечно, и в последнем возможно удаление и замена символов стандартными клавишами Delete или Backspace, но, как и в случае с навигацией, возможности командного режима в этом отношении много шире.

Так, наряду с удалением единичного символа в позиции курсора (x) или перед ней (X), возможно удаление слова (dw), строки (dd) или ее части перед (dD) или после (dG) курсора, предложения (d)) или абзаца (d}).

Как и навигационные команды, команды редактирования могут использоваться с численными аргументами. Так, команда 5dd удалит текущую строку и еще четыре строки вниз. А с помощью команды 3dw можно удалить три слова подряд (включая то, на котором находится курсор).

Не меньше команд отвечает за копирование фрагментов, их вставку и замену. Например, команда yw копирует "маленькое" слово, yW - "большое", yy - строку, y) - предложение, y} - абзац. Командой же p удаленный или скопированный фрагмент вставляется в позицию курсора.

Действие ошибочно введенных команд редактирования может быть отменено командой u (от undo). Вторичный ввод этой команды приведет к отмене предыдущего действия, и так далее. Для возврата ошибочно отмененной операции используется команда Control+R.

Описание всех команд редактирования заняло бы слишком много места. Подчеркну лишь, что, как и в случае с навигацией, нажатием одной-двух клавиш можно удалить, скопировать, вставить и переместить текстовый блок практически любого размера - от единичного символа до произвольного их количества (строки, предложения, абзаца, экранной страницы).

Команды перехода могут рассматриваться как подмножество команд редактирования нормального режима, после которых возможен ввод новых символов и их последовательностей.


Кроме уже упомянутых a и i (ввод после курсора и в его позиции, соответственно), к ним относятся:

A - ввод текста в конец строки;

I - ввод в начало строки;

o - создание новой строки под текущей с возможностью ввода в нее текста;

O - создание новой строки над текущей, в которую также можно ввести текст.

Как и большинство прочих команд редактора vi, команды перехода могут использоваться с числовыми аргументами. Так, если дать команду 3a и после этого ввести некоторую последовательность символов, по выходе в командный режим (клавишей Escape) она будет повторена трижды. Аналогично, ввод текста после команды #O даст # идентичных строк.

Редактор vi располагает средствами поиска и замены текстовых фрагментов, в том числе и с использованием регулярных выражений. Для этого предназначена команда командного режима :s (от substitute). Она дается в форме

:#s/text1/text2/опция

где # - количество строк, в которых операции поиска и замены должны осуществляться (без указания его действие команды распространяется только на текущую строку. Если поиск и замену необходимо выполнить по всему тексту документа, дается команда :%s.

Следует подчеркнуть, что если не указать заменяющего текста (и опций замены), все текстовые фрагменты, указанные в качестве заменяемого текста, будут просто удалены. Во избежание этого используются опции команды :s. Так, опция /c предписывает запрос подтверждения на замену для каждого найденного фрагмента.

И поиск, и замена в vi возможна только для последовательности символов, составляющих одну строку (то есть не содержащей символа LF). Заменяющая последовательность символов также должна образовывать единую строку.

Описанным не исчерпываются возможности редактора vi. В частности, он (вернее, его клон Vim) поддерживает язык макрокоманд и допускает их протоколирование. В комплекте с редактором (в каталоге /usr/local/share/vim/vim###) имеется большое количество таких макросов. Там же - и детальная документация по их применению.

Функциональность редактора Vim в значительной мере зависит от его настроек.


Пример конфигурационного файла (vimrc_example.vim) можно обнаружить в том же каталоге (/usr/local/share/vim/vim###). Его следует скопировать в свой домашний каталог под именем ~/.vimrc и отредактировать по потребностям.

В частности, именно в этом файле можно обеспечить работу клавиш нормального режима при кириллической раскладке клавиатуры. Для этого в него вносится строка

set langmap=

в которой далее перечисляются все символы кириллической раскладки (и в верхнем, и в нижнем регистрах) попарно с соответствующими символами раскладки латинской, разделяя пары запятой без пробела:

set langmap=ё,Ё~,йq, ... Б

Правда, чтобы это сработало, Vim должен быть собран с опцией big, задаваемой в командной строке при исполнении сценария ./configure.

А вообще редактированием файла ~/.vimrc Vim может быть адаптирован для задач любого рода, например, работы с html-документами. На сайте http://www.vim.org имеется большое количество примеров конфигурационных файлов такого рода.


Вводные замечания


Пользователи Windows в качестве универсального средства для работы с текстами в большинстве случаев используют программы, именуемые word-процессорами. Однако в POSIX-системах именно редакторы - традиционный инструмент всех Unix-систем.

Все текстовые редакторы POSIX-мира можно разделить на два класса - редакторы командного стиля и меню-ориентированные редакторы. В первых навигация по тексту и его обработка осуществляется отдачей прямых директив, вроде: перейти на пять слов вперед, удалить пятую снизу строку, заменить строку номер пятнадцать и т.д. Действия в меню-ориентированных редакторах, как и следует из названия, осуществляются более интерактивно (и - более привычно для пользователя Windows-редакторов).

Разделение редакторов на командные и меню-ориентированные, отчетливо выраженное для консольных представителей этого семейства, несколько сглаживается при переходе к работе в графическом режиме. Потому что в Иксах даже типичные командные редакторы обретают часто (при соответствующих опциях сборки) элементы визуального интерфейса. Однако командная сущность gvim или kvim не меняется от того, что они обретают меню в стиле Gtk или KDE, соответственно. А, например, NEdit являет собой вполне гармоничное сочетание командного и визуального стилей редактирования - хотя без соответствующих настроек об этом можно и не догадаться.

Текстовые редакторы обладают рядом преимуществ перед процессорами - по крайней мере, в той области, для которой они предназначены, то есть при создании и обработке текстов. Главное из них - это универсальность. Поскольку выходной материал в редакторах представляет по определению чистый ASCII-файл, он может быть прочитан в любой среде и на любой платформе, не требуя специальных конвертеров (и, тем более, программ, в которых этот материал создавался). Что особенно важно для документов с символами кириллицы. Кроме того, с помощью редакторов можно готовить html-страницы, осуществлять верстку документов для TeX, править конфигурационные файлы, писать исходники программ и многое другое.


Кроме того, редакторы существенно удобнее процессоров для составления длинных структурированных текстов нарративного характера. Каковое, особенно при претензиях на оригинальность, требует сосредоточенности, трудно достижимой при изобилии форматирующих возможностей процессоров. Впрочем, это - мое субъективное мнение. Однако остается фактом, что подготовленный в редакторе документ в дальнейшем может быть трансформирован в любой текстовый процессор или систему верстки, где его можно подвергать любому оформлению.

Сказанное выше относится ко всем текстовым редакторам, как командным, так и визуальным. Тем не менее, и внутри этого семейства первые имеют определенные плюсы по сравнению со вторыми. Последние, конечно, легче в освоении, особенно при эпизодическом использовании. Однако при превышении некоего минимального уровня практических навыков командные редакторы обеспечивают много большую скорость работы. Доказать это количественными измерениями довольно сложно (поскольку определяется пресловутым человеческим фактором), но имеющие соответствующий опыт, думаю, со мной согласятся. Остальных же прошу поверить на слово - все сказанное выше опробовано на собственной шкуре и выстрадано годами создания текстов самого разного объема, характера и назначения.

Следует заметить, что большинство традиционных Unix-редакторов принадлежат к командному классу. Среди его представителей, с одной стороны, - наиболее простые и легковесные (с точки зрения требований к ресурсам) программы. К ним принадлежит, например, редакторы nano и ee, описанные в ближайших разделах.

С другой стороны, именно командными редакторами являются наиболее мощные инструменты комплексной обработки текста, такие, как vi (вернее, его современная модификация - vim) и emacs.

Наконец, существует категория редакторов, занимающих по своей функциональности промежуточное положение между мощными средствами типа vim и emacs, и совсем простыми редакторами класса nano. Среди них - типично командный редактор для консоли - joe.



Чем же руководствоваться при выборе редактора? Как известно, всякому овощу - свой фрукт. И если стоит задача достижения максимальной функциональности - с emacs или vim мало кто в состоянии конкурировать (не зря же emacs удостоился звания операционной среды - того же титула, который некогда присвоила Microsoft своему перлу, Windows 3.x). При потребностях более скромных (и преимущественно - не программерских) есть смысл присмотреться к редакторам промежуточной группы. А вот если основная задача выбираемого редактора - правка конфигурационных файлов, возникает вопрос - а почему бы не ограничиться программами легчайшей весовой категории?

К тому же проблема выбора редактора, как и все в жизни, имеет оборотную сторону: чем богаче возможности, тем больше времени требуется на их освоение. А если претензии на первое время невелики, но это самое первое время - ограничено, выбор редакторов-легковесов как бы напрашивается.

Поэтому в настоящей главе будут кратко охарактеризованы простейшие редакторы nano и ee, выполняющие роль инструментов конфигурации во многих дистрибутивах Linux и в BSD-системах-соответственно. Столь же кратким будет введение в работу с vim - потому что это то средство, которое гарантированно будет под рукой в любой Unix-системе. И, наконец, подробному рассмотрению подвергнется joe - самый мощный из консольный редакторов промежуточной категории.


Заключительные соображения


И так, чем же может привлечь пользователя редактор joe? На мой взгляд, многим. Разумеется, если он, то есть пользователь, вообще испытывает потребность в консольном редакторе.

Во-первых, в его пользу - относительная (по сравнению, скажем, с vim или, тем более, emacs) простота освоения и использования. Немаловажно, что элементарные действия по вводу и редактированию текста в нем могут осуществляться (в том числе и) привычным для выходца из мира DOS/Windows способом.

Второй плюс - единообразность модели выполнения команд, особенно отчетливо проступающая в сравнении с emacs. Модель эта логична и легко запоминается, в том числе и благодаря мнемоническому характеру литерных клавиш, сочетающихся с управляющими.

Если же сравнивать joe с меню-ориентированными редакторами, такими, как mcedit или le, то его отличают а) очень высокая степень настраиваемости (практически не уступающая классическим редакторам командного стиля), и б) быстрота выполнения основных операций по вводу и редактированию. Впрочем, конечно, быстрота эта (как и во всех командных редакторах) достижима только при наработке определенного минимума практических навыков, желательно - доведенных до рефлекторного уровня.

Однако подчеркну, что такие навыки появляются достаточно быстро. И, кроме того, имеются альтернативные им, традиционные (для DOS/Windows) приемы навигации по тексту и прочее. Что приближает joe по простоте использования к меню-ориентированным редакторам и делает его пригодным и для эпизодического использования. Чего, в общем случае, нельзя сказать ни о vim, ни о emacs - эффективное их использование возможно только при постоянной практике.

Весьма удобными представляются средства одновременной работы с большим количеством документов и обмена данными между ними. Возможность независимого просмотра различных частей одного файла в отдельных окнах также следует отнести к числу достоинств (коими обладаютне все консольные редакторы).

Достаточно просто реализована возможность вставки специальных символов, escape-последовательностей и тому подобных вещей.
Что гармонично дополняется возможностью определения для joe клавиатурной раскладки, отличной от используемой в консоли по умолчанию.

Очень эффективно применение joe для составления и редактирования пользовательских сценариев командой оболочки - благодаря возможностям временного выхода в командную строку - раз, запуску единичной команды внутри редактора - два, и открытию почти полноценного сеанса командной оболочки изнутри него же (с возможностью записи в виде файла) - три. Судя по документации и конфигурационным файлам, есть средства и для более сложных программистских упражнений, но об их эффективности судить я не компетентен.

Наконец, главное достоинство joe - простота адаптации к специальным задачам, не требующая ни программирования на LISP, ни иных сильнодействующих средств. Она вполне достижима элементарным протоколированием макрокоманд и несложным их редактированием. Вероятно, такие возможности покажутся смешными записному программисту, но пользователю, профессионально связанному с подготовкой нарративных текстов, они в большинстве случаев более чем достаточны.

К принципиальным упущениям joe можно отнести, пожалуй, только отсутствие режима переноса символов без образования новой строки, подобного умолчальным для vim или emacs: режим word wrapping приводит к разрыву непрерывности абзаца (что в дальнейшем может создать сложности при автоматизированной обработке текста средствами sed или awk), а его отключение - к неудобству набора.

Иными словами, joe - достаточно мощный и удобный инструмент для работы с текстами. Он может быть использован и при периодических работах (вроде правки конфигурационных файлов или составления небольших документов). Но наиболее эффективно применять joe при повседневной работе с большими и структурированными нарративными текстами, особенно - предназначенными для публикации в Сети. Среди всех консольных редакторов joe отличается близким к оптимальному соотношением простоты, мощности и настраиваемости. А посему беру на себя смелость рекомендовать его всем любителям работы в текстовом режиме, буде до сего времени они не приобрели иных пристрастий.




Икс - он и в Африке X


Если текстовый режим работы в каждой POSIX-совместимой операционке обеспечивается ее собственным консольным драйвером, то за режим по настоящему графический в любой из них отвечает (почти) одна и та же программа - оконная система X или, в просторечии, Иксы.



Иксы: принципы организации


Что же представляют собой Иксы? Одно из определений (заимствованное из статьи Андрея Зубинского гласит, что это - не зависящая от платформы растровая графическая оконная система, обеспечивающая прозрачное использование ее ресурсов с помощью сетевых соединений. Определение верное, но вызывающее больше вопросов, чем дающее ответов. Которые мы и попробуем наметить.

Независимость от платформы, пожалуй, в объяснениях не нуждается - как я уже говорил, Иксы функционируют на любом "железе" и поверх любой операционки. Единственное требование - способность видеосистемы данной платформы хоть как-то воспроизводить графику. Причем - графику растровую - растровый характер Иксов определяется тем, что они работают только с устройствами вывода, обеспечивающими попиксельное отображение информации, а не символьное, как текстовая консоль, и не векторное (впрочем, векторных видеосистем я никогда не видел, хотя говорят - есть такие). Оконная же она потому, что имеет более высокий, нежели пиксель, уровень абстракции - "окно" (window), лежащий в основе всех интерфейсных элементов: и собственно окон (в понимании Windows), и кнопок, и ниспадающих меню, и строк ввода и даже обрамления вокруг окон.

Сетевой характер системы X Window обусловлен ее моделью - клиент-серверной, в которой взаимодействие между сервером и клиентами осуществляется (даже на локальной машине) за счет специального сетевого X-протокола. По этому протоколу происходит также любое взаимодействие между клиентскими программами Иксов, и их связь с главной Иксовой библиотекой - Xlib.

Именно сервер и клиент - первое из базовых понятий системы X. При этом понимание их кажется обратным общепринятому: в качестве сервера выступает аппаратно-зависимая программа ввода/вывода (она так и называется - X-сервер, и именно в ней кроются главные различия между различными реализациями Иксов), непосредственно взаимодействующая с "железом" - видеоустройствами (адаптером и монитором), клавиатурой и мышью. X-сервер предоставляет свои ресурсы клиентам - прикладным программам, обеспечивающим остальные функции.
То есть сервером в общем случае является локальный терминал, тогда как клиентская часть может исполняться и на удаленной машине.

Впрочем, для персонального компьютера это не принципиально. Более важным здесь оказывается другое базовое понятие - дисплей. Под которым в данном случае понимается отнюдь не экран монитора - вернее, не только он один, но его комбинация с устройствами ввода и позиционирования, сиречь клавиатурой и мышью. В случае персонального компьютера такой физический X-дисплей представляет собой просто нашу наличную машину. Хотя, теоретически рассуждая, к одной машине можно прикрутить несколько дисплеев - благо двухмониторные карты нынче не редкость, и USB-разъемов для подключения дополнительных клавиатур и мышей обычно также в достатке.

Маленькое отступление. Очевидно, что для открытия дисплея - то есть запуска на нем X-сервера, - последний должен взаимодействовать с аппаратурой, его составляющей, то есть быть совместимым с нею. И если мыши и особенно клавиатуры давно стандартизированы, и сложностей здесь обычно не бывает, то многообразие видеокарт до недавнего времени часто оказывалось камнем преткновения при использовании Иксов. Именно в области поддержки видеоадаптеров и различаются между собой в первую очередь отдельные их реализации. И сильной стороной коммерческих X-серверов был как раз широкий спектр поддерживаемого видеооборудования. Ныне многообразие видеокарт в прошлом, а все существующие практически одинаково хорошо поддерживаются всеми X-серверами, в том числе и свободными. Тем не менее, нужно понимать: когда говорят о поддержке, например, в Linux (или даже в конкретном его дистрибутиве) той или иной видеокарты, имеется ввиду именно ее совместимость с Иксами, а не с операционной системой как таковой.

Один и тот же физический X-дисплей в состоянии воспроизводить некоторое количество дисплеев виртуальных - аналогов виртуальных консолей текстового режима. Каждый из них целиком занимает собственную виртуальную консоль - поэтому для запуска запуска Иксов необходимо, чтобы хотя бы одна из таковых была доступна (для ядра ОС) и неактивизирована (процессом типа getty).


Общее количество X-дисплеев для 32- разрядных компьютеров составит 232, нумеруемых с 0.

Каждый виртуальный дисплей может содержать множество окон - отображаемых областей растровой памяти. Окна образуют строгие иерархии на основании простого правила - в каждом экране по умолчанию существует одно уникальное окно-родитель (корневое, или root-окно), каждое окно должно иметь "родителя" и само может быть "родителем" для других окон. Окна могут создаваться, перерисовываться, удаляться, в них может выводиться текстовая и графическая информация.

Между окнами возможен обмен данными через буферы памяти - в отличие от консольного режима (и, добавлю, в отличие от Windows), Иксах таких буферов задействовано несколько. Один из них - обычный экранный буфер, подобный консольному: информация в него помещается при выделении мышью или стрелками клавиатуры, и вставляется нажатием средней кнопки мыши. Остальные буферы памяти требуют принудительного копирования в них выделенного фрагмента - например, привычной по Windows комбинацией клавиш Control+C или Control+X, после чего вставляется также каким-либо специальным способом (например, через Control+V). Однако это уже зависит от реализации в конкретных программах (хотя все больше приложений поддерживает "подоконные" сочетания "горячих клавиш"). К сожалению, способов обмена данными между X-дисплеем и текстовыми консолями не существует (по крайней мере, я никаких указаний на этот счет не нашел)

Кроме этого, X-сервер обеспечивает рендеринг шрифтов - претворение их формального описания из специальных шрифтовых файлов разного формата в те самые буквы, которые мы видим на экране. Впрочем, эта функция может быть возложена на отдельный шрифтовой сервер (Xft - X Fonts Server).

Функции X-сервера осуществляются за счет специальной библиотеки - Xlib. Она обеспечивает открытие дисплея и взаимодействие с ним любой клиентской программы, создание и уничтожение окон, а также их отображение вместе с некоторыми простыми атрибутами.



Важно, что сам по себе X-сервер (вместе с Xlib) ни коим образом не способен управлять элементами пользовательского интерфейса - даже собственными окнами, которые он воспроизводит. Забегая вперед, замечу: чтобы получить представление о возможностях чистых Иксов (точнее, отсутствии таковых), можно для пробы запустить голимый X-сервер. Делается это командой (из текстовой консоли)

$ X

каковая представляет собой символическую ссылку на исполняемый файл X-сервера - /usr/X11R6/bin/XFree86 или /usr/X11R6/bin/Xorg (для соответствующих реализаций). После чего можно наблюдать за перемещением крестообразного курсора по серо-решетчатому фону - и ничего более. Правда, есть еще и возможность прервать X-сеанс - комбинацией клавиш Alt+Control+BackSpace; к слову сказать, это универсальный способ выхода из графического режима, к которому приходится прибегать, если штатные средства выхода почему-либо не работают.

Для использования мощи X-сервера в мирных целях он должен быть запущен совместно с какой-нибудь клиентской программой. В простейшем случае такой программой может быть так называемый эмулятор терминала (или просто X-терминал), который, таким образом, оказывается непременных компонентом оконной системы X, и в комплект ее входит его разновидность под названием xterm. Впрочем, часто под словом X-терминал понимают и аппаратное решение - слабые рабочие станции, служащие только для запуска X-сервера, а для работы клиентских программ использующие ресурсы мощных компьютеров.

Работа в окне X-терминала полностью имитирует действия в консоли: здесь запускается отдельный экземпляр пользовательского шелла, позволяющего вводить команды, в том числе и фоновые, и запускать любые программы текстового режима (например, редактор, файловый менеджер, браузер), которые будут исполняться в том же окне.

Позволяет терминал запускать и программы графического режима, специально предназначенные для работы в оконной системе X. Такие программы, в отличие от консольных, будут исполняться в собственном, отдельном от терминального, окне.


А поскольку Иксы наследуют многозадачный режим, поддерживаемый операционкой, на которую они наложены (а любая операционка POSIX-семейства - многозадачна), то таких программ можно запустить много - пользуясь, например, средствами запуска в фоновом режиме командной оболочки. И каждая запущенная программа будет исполняться в отдельном окне. Однако средств управления окнами ни сами Иксы, ни тем более терминал не предоставляют - так что даже переключаться между такими задачами окажется затруднительно.

Таким образом, чтобы в полной мере воспользоваться возможностями, предоставляемыми Иксами совместно с базовой ОС, потребуется еще одна программа, которая осуществляет управление окнами - их открытием, закрытием, представлением на экране, масштабированием, перемещением, фокусировкой и так далее. Почему она и называется - менеджер окон. И которая уже и являет графический интерфейс пользователя (GUI - Graphic User Interface) в полном смысле слова: вид всех управляющих элементов (рамок окон и их заголовков, полос прокрутки, меню, кнопок и пиктограмм определяется именно оконным менеджером.

В комплект Иксов штатно входит оконный менеджер под названием twm. Это весьма архаичная программа с ограниченными возможностями. А вообще менеджеров окон существует бессчетное множество, и специальный разговор о них впереди. Здесь они упомянуты лишь потому, что без них, в сущности, невозможно не только практическое использование Иксов, но даже и иллюстрация их возможностей или проверка правильности настройки.

Кроме этого, в комплект Иксов входит еще множество клиентских программ - утилит и приложений. Одни из них (xvidtune, xfontsel) широко используются в настроечных целях, другие (например, текстовый редактор xedit) давно вытеснены из обихода более совершенными аналогами и сохраняются в качестве реликтов.

Впрочем, и сами Иксы на фоне таких графических систем, как Windows и особенно MacOS, производят впечатление реликта эпохи. Эпохи мирного сосуществования множества аппаратных платформ и операционных систем, для взаимодействия с которыми Иксы и разрабатывались.


Ибо понятно, что за такой универсализм приходится расплачиваться - в первую очередь потерей производительности и требовательностью к ресурсам, в первую очередь к памяти. Ибо хотя сам по себе X-сервер - программа достаточно неприхотливая и готова довольствоваться 16 Мбайт суммарной (физической и виртуальной) памяти, уже самый простой оконный менеджер с несколькими пользовательскими приложениями эти требования как минимум удваивает или утраивает. И при этом быстродействие их, в сравнении с Windows-аналогами, отнюдь не поражает воображения.

Мощные интегрированные среды, такие, как KDE, и сложные комплексные приложения, типа OpenOffice, Mozilla, GIMP и так далее, начинают более-менее шевелиться при объемах физической памяти от 256 Мбайт. Правда, с увеличение объема памяти сверх этого и быстродействие "тяжелых" приложений возрастает, достигая оптимума при 512 Мбайт (правда, по современным масштабам это не кажется чем-то из ряда вон выходящим).

Не способствует повышению быстродействия и сама клиент-серверная модель построения Иксов, в которых каждое взаимодействие между процессами имитируется сетевым соединением. А если вспомнить еще и о незащищенности X-протокола - то модель эта создает определенную угрозу безопасности. Не случайно одна из настоятельных рекомендаций в этом отношении - никогда не запускать на сетевой машине Иксы от лица суперпользователя.

Есть у Иксов и другие недостатки. Один из важнейших с точки зрения пользователя - низкие скорость и качество рендеринга шрифтов. Что в сочетании с из рук вон плохим качеством самих шрифтов, особенно кириллических, дает подчас эффект просто ужасающий. И хотя за последние годы и в отношении рендеринга, и в плане улучшения самих шрифтов достигнуты определенные успехи, принципиального изменения ситуации пока не произошло.

И тем не менее Иксы использовались, используются и будут использоваться во всех POSIX-системах еще долгое время (возможно, вечно). По двум причинам. Во-первых, как сказал бы товарищ Сталин, другой графической системы у нас, POSIX'ивистов, нет.А во-вторых, многочисленные недостатки Иксов компенсируются полной изоляцией графической среды от базовой ОС и ее системного окружения, с одной стороны, и клиентских программ от X-сервера - с другой. В результате чего ошибки исполнении пользовательских приложений крайне редко приводят к краху самих Иксов и практически никогда - всей операционной системы. И потому Иксы в сочетании с операционками POSIX-семейства применяются и будут применяться везде, где критичной оказывается бессбойная работа системы. А это - все машины производственного назначения, не так ли?


Иксы: сборка из исходников


Знакомство с Иксами начинается с их установки. Собственно, никто не понуждает пользователя выполнять эту процедуру вручную - в большинстве пакетных дистрибутивов они устанавливаются автоматически, да ещё обычно по умолчанию, при первичной инсталляции. Однако при этом они подчас тянут за собой столько разного и непонятного, что возникает резонное желание разобраться, что из этого приблудного софта действительно необходимо, а что относится к архитектурным излишествам. А для этого необходимо хоть раз установить Иксы самому.

Сделать это можно из прекомпилированных пакетов - таковые входят в состав любого полнофункционального дистрибутива, - руководствуясь методами принятого в данной системе пакетного менеджмента (rpm там, apt-get, порты FreeBSD или портежи Gentoo, и так далее). Если версия из дистрибутива окажется недостаточно свежей - для многих распространённых дериватов Linux (Red Hat, Suse, Mandrake, Slackware, Debian), FreeBSD, OpenBSD, NetBSD более свежую бинарную сборку XFree86 можно получить с сервера проекта: . В частности, нынче это основной способ получения XFree86 для тех систем, которые официально от этой реализации Иксов отказались.

Однако самый охмуреж - это собрать Иксы из исходников, да ещё в соответствие с собственными представлениями об оптимизации. Тем более что это - единственный пока способ ознакомиться с новейшими версиями "правильных" Иксов от Xorg, если они не успели попасть в дистрибутив - в бинарном виде эта реализация на сайте проекта недоступна, распространяясь только в виде исходных текстов.

Так вот, оказывается, что для установки Иксов необходимо и достаточно иметь архивы их исходных текстов. Ну и, конечно, Base Linux - Иксы прекрасно ставятся на чистый LFS Герарда Бикманса. Или, например, на минимальный установочный комплект FreeBSD или DragonFlyBSD.

В современном своем виде исходники Иксов разбиты на семь тарбаллов. В реализации от XFree86 они имеют вид XFree86-4.5.0-src-[1-7].tgz, в варианте от Xorg - X11R6.8.2-src[1-7].tar.gz, суммарным объемом более 50 и 70 Мбайт, соответственно.
Только они и необходимы - прочее, что можно найти в каталоге src на серверах проекта (утилиты, документация и прочее) относится к категории опционального (ИМХО - очень опционального). Так что скачиваем тарбаллы, помещаем куда нужно, переходим в каталог, предназначенный для исходников и разворачиваем архивы любым удобным способом. Например, вот так:

$ find /path_to_src -name XFree86-4.5.0-src-?.tgz \ -exec tar xzpvf {} \;

После чего все исходники оказываются в одном каталоге - xc. Переходим в него и внимательно читаем файл INSTALL-X.org (BUILD в реализации от Xorg) - по крайней мере, его начало. Из которого выясняется, что установка Иксов на самом деле очень проста, и сводится к двум основным командам:

$ make World $ make install

И одной дополнительной (опциональной):

$ make install.man

Вывод этих команд к тому же можно перенаправить в файл, например

$ make World >& world.log

освободив тем самым командную строку нашей консоли для общественно-полезной деятельности. Что отнюдь не лишнее - сборка Иксов даже на мощной машине может занять не один час.

Возникает резонное желание, однако, предварительно задать некоторые условия оптимизации. Заметим сразу, что обычные флаги gcc, заданные в переменной CFLAGS (в командной ли строке, или в общем профильном файле) не окажут на процесс компиляции никакого влияния. Чтобы сборка проходила с оптимизацией, флаги эти нужно определить в переменной BOOTSTRAPCFLAGS:

make World BOOTSTRAPCFLAGS="значения"

Я, например, обычно определяю ее так:

BOOTSTRAPCFLAGS="$CFLAGS"

в sh-совместимых оболочках, и

setenv BOOTSTRAPCFLAGS $CFLAGS

в tcsh. А значения переменной CFLAGS заданы в профильном файле так:

export CFLAGS="-O2 -march=pentium4 -fPIC"

или

setenv CFLAGS "-O2 -march=pentium4 -fPIC"

для zsh и tcsh, соответственно. Разумеется, процессор должен соответствовать объявленному в -march. Обратим также внимание на флаг -fPIC. Он необходим только в том случае, если в дальнейшем исполняемые файлы и библиотеки предполагается подвергнуть предварительному связыванию программой prelink (в Linux).Если таковое не предвидится (или невозможно, как в BSD-системах) - его можно опустить.

Вот, собственно, и все - не пройдет и часа (двух, трех - в зависимости от мощности машины), как вы станете счастливым обладателем работоспособной и полнофункциональной системы Икс. И, повторяю, ничего, кроме перечисленного выше (то есть семи архивов и толики свободного времени) для этого не потребуется.


Кто Вы, мистер Икс?


Иксы часто воспринимаются как неотъемлемая часть Linux - благодаря юзер-ориентированным дистрибутивам этой ОС. Однако на самом деле к Linux'у они не имеют никакого отношения, за исключением того, что могут быть запущены (в том числе и) поверх него. Как, впрочем, поверх Free- или OpenBSD, а также любого Unix'а и Unix-подобной системы. И не только: помнится, в своё время Иксы были портированы на OS/2. А еще приходилось слышать, что существует и Windows-реализация каких-то X-серверов. Потому что, вообще говоря, Иксы изначально были разработаны для того, чтобы запускаться на любом железе и в любой операционке, способных поддерживать растровую графику (и немного - на том, что к поддержке графики органически не способно:-)).

К слову - о названии. Со всем известным именем Самой Великой Операционной Системы (не к ночи будь помянута) оно никак не связано. В оригинале, то есть по-английски, система эта называется X Window System, наиболее точным переводом чего будет - Оконная Система Икс. Ну, что это - Система, интуитивно понятно. Прилагательное "Оконная" призвано отличать её от полноэкранных графических сред (были ведь и такие; в начале 90-х каждая уважающая себя DOS-программа считала своим долгом обзавестись собственным графическим интерфейсом, функционирующим, как правило, именно в полноэкранном режиме).

И, наконец, X - это имя собственное. И возникло от того, что непосредственно по времени ей предшествовала другая графическая система, носившая имя W - от слова Window, ибо также была оконной. Так что те, кто еще не забыл латинский алфавит, легко могут понять происхождение литеры X в названии системы. И потому попадающиеся в литературе псевдо-переводы типа система X Window (а подчас даже система X Windows) гораздо хуже передают суть дела, чем краткое жаргонное словечко - Иксы, каковое я и употребляю в этой книге.

История Иксов уходит в седую древность - 1984 год, и у истоков ее - трое разработчиков, Роберт Шейфлер (Robert Sheifler), Джим Геттис (Jim Gettys) и Рон Ньюмен (Ron Newman).
В дальнейшем разработкой Иксов занимался Массачуссетский технологический институт (MIT) и фирма DEC. В 1987 году разработчики Иксов, при участии ряда компьютерных фирм, создали организацию под названием X Consortium, которая приступила к распространению оконной системы X открыто и свободно, под собственной лицензией, сходной с GPL и, особенно, BSD.

За время жизни оконная система X сменила множество версий, из которых последней на долгие годы (и по сей день) стала 11-я. Видоизменения внутри которой получали статус релизов, нынешний из которых - 6-й, почему вся система сокращенно и называется X11R6 - также отличается далеко не юным возрастом. Наконец, внутрирелизные вариации также нумеруются - и потому на сей момент последний вариант Иксов носит такой, весьма запутанный, титул: X11R6.8.2.

Сами по себе Иксы - это не какая-либо конкретная программа, и даже не графический интерфейс как таковой, а лишь набор спецификаций, которым этот самый графический интерфейс (точнее, даже метаинтерфейс - как скоро станет ясно, никаких средств взаимодействия с пользователем сами по себе Иксы не содержат) должен соответствовать. Конкретная же их реализация - целиком на откупе (и на совести) разработчиков конкретных же систем. И потому на базе Иксов было построено множество самостоятельных графических метаинтерфейсов, большинство из которых - проприетарные, закрытые и распространяются за деньги (подчас немалые). Среди таких реализаций мне известны Metro-X и Accelerated-X - они использовались в проприетарных же Unix-системах. Хотя и подборки Linux, выпускавшиеся известной компанией Walnut Creek, одно время комплектовались некоторыми версиями коммерческих серверов.

Однако пользователь Linux, FreeBSD и любой другой свободной операционки имеет дело, как правило, только со свободными реализациями же X-спецификаций. До недавнего времени здесь следовало употребить единственное число, потому что такая реализация существовала в единственном экземпляре. И имя ей было (да и по сей день есть) - XFree86, что, как несложно догадаться означало: свободные Иксы для платформы x86, разрабатывающиеся в рамках одноименного проекта (http://www.xfree86.org).


Она также имеет собственную лицензию, которую адепты FSF до недавнего времени полагали "правильной". Однако выход релиза XFree86 4.4 в начале 2004 года, сопровождавшийся сменой лицензионной политики, изменил ситуацию: теперь она полагается злостным порождением (ну, не знаю чего - мирового империализма, вероятно) и в звании GPL-совместимой ей отказано.

В связи с этим в народе возник новый проект, именуемый Xorg. Он основывается на последней бета-версии XFree86 4.39, которая имела еще "правильную" лицензию и, в общем и целом, соответствует этой версии по содержанию.

Похоже, однако, что отделение проекта Xorg всем пошло на пользу. В том числе и проекту XFree86, который активизировал свою деятельность, выпустив весной 2005 г. версию 4.5, содержащую множество усовершенствований. Впрочем, как официальный компонент дистрибутива она вошла только в NetBSD.

Таким образом, на данный момент мы имеем несколько неопределенную ситуацию, а именно - сосуществование трех свободных реализаций Иксов:

"неправильной" XFree86 4.5, которую, тем не менее, многие разработчики как Linux-дистрибутивов, так и BSD-систем включают, в той или иной форме, в свои поставки;

"правильной" Xorg (последняя версия на момент данного сочинения - X11R6.8.1), которая медленно, но верно внедряется в качестве "Иксов по умолчанию";

старой доброй (хотя на счет последнего существуют и иные мнения) XFree86 4.3, сохраняемой как компонент здорово-консервативных систем (FreeBSD - пример которых).

Мне не хотелось бы заморачиваться юридическим крючкотворством. Хотя новую лицензию XFree86 4.4, в меру своего понимания вопроса, прочел, и ни малейшей крамолы в ней не обнаружил (кроме требования об упоминании, напомнившее оговорку о рекламе в старой BSD-лицензии, вокруг которой столько ломали копий еще несколько лет назад). И по поводу чего не могу не вспомнить одну из своих любимых аналогий - со спорами либералов, социал-демократов и прочих анархистов: как известно, у большевиков в лагерях и расстрельных подвалах место для всех нашлось...



Так что далее речь пойдет о неких абстрактных Свободных Иксах (или Иксах просто) - тем паче, что, по моим наблюдениям, принципиальных различий между XFree86 и Xorg не просматривается. Если не считать, конечно, разных названий исполняемых и конфигурационных файлов - так что в необходимых местах я буду делать соответствующие оговорки.

Иксы предназначены для установки на любой из свободных Unix-клонов (и не только свободных - те же самые Иксы используются в Solaris для платформы Intel, возможно - и в других проприетарных Unix). Важно понимать, что когда речь идёт об Иксах в каком-либо дистрибутиве Linux или любой ОС из клана BSD. мы имеем дело с одним и тем же исходным кодом одной из двух их свободных той же реализаций, а мелкие различия между ними обусловлены либо номером версии, либо именем реализации, либо особенностями сборки под конкретную платформу, либо, наконец, предпочтениями майнтайнеров конкретного дистрибутива. И потому установка и настройка Иксов в любой из этих систем осуществляется одними и теми же методами.

Вернее, может успешно осуществляться - потому что майнтайнеры систем часто придумывают собственные инструменты для конфигурирования графического режима. Однако повторяю: если инструменты эти почему-либо не позволяют добиться оптимального результата, пользователь любого дистрибутива Linux, Free-, Net- или любой иной BSD всегда может обратиться к универсальным, собственно Иксовым, средствам. О них-то в первую очередь и пойдет разговор в последующих разделах этой главы.


Немного о раскладках


Упомянув об эмуляторах терминала и менеджерах окон, я несколько забежал вперед - однако без какой-либо из клиентских программ этого семейства невозможно даже проверить правильность настройки Иксов, например, клавиатуры и видеосистемы, а также шрифтов. Конечно, заведомо неподходящий драйвер клавиатуры или видеокарты, а также неправильный путь к умолчальным шрифтам, просто не позволят стартовать X-серверу. Однако огрехи, скажем, русификации раскладки или отсутствие кириллических шрифтов работать ему не помешают - вот только не совсем так, как нам нужно.

Для начала проверяем ввод кириллических символов - прямо в командной строке терминального окна, без запуска какого-либо иного приложения. И с удивлением обнаруживаем - не обязательно, но вполне возможно, - что ничего при этом не происходит, хотя при настройке через xf86config была выбрана русская раскладка. Почему? - спрашиваем сами себя. И сами же себе отвечаем - потому что не позаботились о правильном определении системной локали. Сама по себе локаль, как-будто бы, к Иксам отношения не имеет, но вот ее несоответствие Иксовой раскладке блокирует клавиатурный ввод напрочь. Так что, если это не было сделано ранее, перво-наперво устанавливаем правильную локаль - в соответствии со страной (ru), языком (RU) и используемым набором символов (например, KOI8-R).

Теперь, вполне возможно, что на экране при вводе мы видим сплошную абракадабру. Причина понятна - отсутствие русских шрифтов (или путей к ним в Иксовом конфиге). Однако попытка переключиться на латиницу дает тот же эффект. Вспоминаем, что это мы уже проходили несколькими разделами ранее - при настройке через xf86config выбор русской раскладки клавиатуры подразумевает почему-то, что в латинских буквах у пользователя потребности нет. И там же, в разделе о конфигурации Иксов, ищем рецепт - ручную правку соответствующей секции конфигурационного файла.

Теперь переключение осуществляется нормально, но абракадабра с экрана никуда не исчезает. Что свидетельствует о некоторой напряженке со шрифтами.
Но это будет темой следующего раздела, а пока закончим с раскладками.

Определив все опции клавиатуры, как было описано ранее, получаем нормальную раскладку для win-маркированной клавиатуры (вариант winkeys), с заказанным переключателем и индикатором альтернативной группы. Однако стоит ли останавливаться на достигнутом? Меня, например, всегда просто бесили все стандартные русские раскладки - и та, что была на пишущих машинках (унаследованная dos-маркированными компьютерными клавишами), и win-модификация оной. Поневоле поверишь в то, что вообще раскладка qwerty была придумана для того, чтобы замедлить работу ремингтониста (это - мужской род от слова "машинистка", ввиду большей физической силы при чрезмерно быстрой печати они сильно амортизировали столь дорогостоящие инструменты, каковым были некогда пишущие машинки). А ее кириллические вариации дело еще усугубили - не иначе, на предмет дополнительного снижения амортизации казенной техники. По настоящему удобной представляется только умолчальная русская раскладка FreeBSD (т.н. ru.koi8-r.kbd), в которой знаки препинания находятся на нижнем регистре верхнего ряда, а цифры - на верхнем. Да только уж больно непривычна, и клавиатур, таким образом маркированных, не сыскать.

Тем не менее, я по мере сил и в минимально необходимом объеме всегда пытаюсь выправить положение. Для чего в используемой мной кириллической раскладке перемещаю запятую на нижний регистр, ввожу в нее символ прямого слэша (по умолчанию почему-то обычно имеется только обратный) и доллара (последнее - не из любви к длинному и зеленому, а для обозначения приглашения командной строки). Как это сделать в консоли - можно сообразить. А вот как быть в Иксах?

На теории этого дела останавливаться не буду - она некогда была подробно описана Иваном Паскалем в его труде об Xkb, до сих пор не утратившем своего значения. Так что только пара практических рецептов.

Расширенные возможности управления клавиатурой в Иксах обеспечиваются модулем Xkb. Все относящиеся к нему файлы собраны в каталоге /usr/X11R6/lib/X11/xkb.


В данный момент нас интересует лишь один из его подкаталогов - symbols, файлы которого описывают, как можно понять из его имени, непосредственно наборы символов, привязанные к клавиатурным раскладкам различных стран. Точнее - один из вложенных в него подкаталогов - symbols/pc для одноименной архитектуры. Ну а в нем уже важен файл ru - это непосредственно символы, привязанные к нашей, родной, кириллической раскладке.

Формат файла достаточно прозрачен, и становится понятным при его просмотре: каждому коду клавиши ставится в соответствие два символа - в нижнем регистре и верхнем. Файл разделяется на несколько секций. Первая (Basic) описывает базовую русскую раскладку, остальные представляют собой варианты и содержат лишь изменения относительно базового набора символов.

В данный момент перед нами (вы, конечно, резонно можете возразить - "простите, не нами, а Вами", - хорошо, лично передо мной) стоит задача внести косметические изменения в раскладку ru(winkeys). Начинаю я, однако, с секции Basic:

partial default alphanumeric_keys

xkb_symbols "basic" {

Ибо первый напрашивающийся кандидат на модификацию - это клавиша Left Backslash (Bar на верхнем регистре), по прямому назначению мной никогда не используемая. Отыскиваю ее код (это будет LSGT) и умолчальное значение нижнего регистра backslash заменяем на comma (сиречь запятую). За верхним же регистром резонно сохранить исходное значение - bar.

Позиция, ранее задействованная под запятую в русской раскладке, у меня таким образом освободилась. Не пропадать же добру? - займу-как я ее прямым слэшем. Для чего отыскиваем (то есть я отыскиваю) соответствующую секцию - теперь уже

partial alphanumeric_keys

xkb_symbols "winkeys" {

нахожу в ней нужный код (AB10) и умолчальную comma верхнего регистра меняю на slash. Остается разобраться с любимым баксиком. Его я помещаю на место нормального (правого) backslash, тогда как последний передвигаю на регистр верхний (код их клавиши - BKSL).

И в итоге все модифицированные строки выглядят таким образом (в порядке их исходного расположения в файле /usr/X11R6/lib/X11/xkb/symbols/pc/ru:

partial default alphanumeric_keys

xkb_symbols "basic" {

name[Group1]= "Russian";

... key <LSGT> { [ comma, bar ] }; ... };

partial alphanumeric_keys

xkb_symbols "winkeys" {

include "pc/ru(basic)" ... key <AB10> { [ period, slash ] }; key <BKSL> { [ dollar, backslash ] }; };

Не знаю, как кому - а мне так очень удобно. Единственный минус - после этого работать на чужих машинах становится просто мучительно больно. Создавая таким образом стимул - делать это как можно реже...


Разборки со шрифтами


Разборку эту следует начать с терминологии - для чего вспомним традиции отечественной полиграфической школы. В соответствие с которой набор символов определенного облика (то, что в околокомпьютерной литературе называют обычно шрифтом, а то и фонтом) носит имя гарнитура. В англоязычной литературе ему соответствует выражение Font Family. Примерами классических гарнитур являются - Times, Courier, Helvetica и многие, многие другие.

Визуальные вариации символов каждой гарнитуры описываются термином шрифтоначертание. В большинстве гарнитур вариации эти выделяются на основе насыщенности - нормальное (normal или medium) шрифтоначертание и, скажем, полужирное (bold), и прямое (regular) и курсивное (oblique или italic). Кроме того, некоторые гарнитуры имеют еще и дополнительные шрифтоначертания - такие, как подчеркнутое или перечеркнутое.

Так вот, индивидуальное имя шрифта складывается из названия его базовой гарнитуры и шрифтоначертания (или - шрифтоначертаний), например: Times полужирный курсивный, или Петергбург нормальный подчеркнутый. Строго говоря, именно к сочетанию имени гарнитуры и шрифтоначертаний и относится термин шрифт (font).

Шрифтовые гарнитуры объединяются в семейства по двум независимым признакам. С одной стороны, различают семейства моноширинных и пропорциональных гарнитур. В первом все символы занимают одно и то же место по горизонтали, вне зависимости от их относительной ширины. Это - шрифты пишущих машинок и их имитирующие - Courier, Балтика. В семействе пропорциональных гарнитур под символы, относительно более узкие (например, русское т) отводится меньшее место по горизонтали, чем под символы широкие (скажем щ).

Второй критерий разделения гарнитур на семейства - наличие или отсутствие так называемых серифов (serif), что обычно переводится как засечки, хотя в советском учебнике полиграфии дается более точное обозначение - отсечки (Б.М. Кисин. Графическое оформление книги. ГИСЛЕГПРОМ, 1946, 408 с.). Действительно, это - как бы декоративные дополнительные выступы, которые "отсекают" строку по горизонтали, способствуя фокусировке глаза вдоль нее.
Так вот, гарнитуры, символы которых таковые имеют, объединяются в семейство Serif (шрифты с отсечками), прочие же - в семейство Sans Serif (иногда называемое также Гротеск). Очевидно, что как первые, так и вторые могут быть и моноширинными, и пропорциональными.

Примерами моноширинных гарнитур с отсечками являются упомянутые выше Courier и Балтика (стандартные шрифты латиницы и кириллицы для советских пишущих машинок, соответственно). Пример классических моноширинных гротесков мне на память не приходят, но в компьютерном мире они употребляются очень широко: это вариации на темы Fixed, Lucida Typewriter, Andale и им подобным.

Пропорциональные гарнитуры Serif - это подавляющее большинство гарнитур, представленных в книгах и прочей полиграфической продукции. Исторически большинство из них восходит к классическим гарнитурам Antiqua и Times, ныне же им несть числа: Книжная, Петербург, гарнитура Лазурского... Перечислять можно было бы долго. А если вспомнить про их современные компьютерные вариации - так и вообще можно сбиться со счета. Семейство пропорциональных гротесков, хотя и менее употребимо в полиграфии, но также весьма многочисленно. Это в первую очередь классическая Helvetica и ее многочисленные вариации типа Swiss, вплоть до всем известного компьютерного Arial.

Традиционно в полиграфии использовались преимущественно пропорциональные гарнитуры; моноширинные гарнитуры заняли в ней прочное место лишь в последнее время - для передачи листингов программ, команд и тому подобного хозяйства в околокомпьютерной литературе. Причем гарнитуры с отсечками и гротески занимали каждая свою нишу. Первое семейство предназначалось для передачи длинных и "сплошных" повествовательных текстов, второе же - для коротких текстов блочного характера и, иногда, заголовков. Однако широкое распространение, с одной стороны, компьютерных технологий в "бумажном" издательском деле, с другой - онлайновых изданий, предназначенных для восприятия исключительно или по преимуществу с экрана, существенно сместило сферы применения гарнитур того и другого семейства: гротески стали широко применяться для сплошных текстовых массивов сначала в онлайновых, а затем и "бумажных" изданиях, а гарнитуры семейства Serif - напротив, для декоративного выделения блочных участков.



Интересно, что эксперименты для оценки влияния шрифтов на качество восприятия текста проводились еще задолго до появления компьютеров - в 30-х годах прошлого века (а возможно, и ранее), в частности, в Англии. И результаты их оказались не вполне тривиальными. Конечно, общепринятое мнение о том, что восприятию сплошных текстовых массивов более способствуют гарнитуры с отсечками, подтвердилось. Но только - для людей а) взрослых и б) образованных. Дети и люди малограмотные даже сплошные массивы лучше воспринимали в исполнении гротескными гарнитурами.

И еще выяснилось, что для текста, подвергнутого искажениям, читабельность лучше (или, скажем так, менее плохо) сохраняется именно в случае использования шрифтов без отсечек. Последнее имеет прямое отношение к использованию компьютерных шрифтов. Ведь на экране текст всегда в той или иной мере подвергается искажениям - за счет кривизны CRT-трубок, пикселизации, да и просто недостаточно высокого качества рендеринга. И потому в качестве экранных шрифтов гротески почти всегда оказываются предпочтительными. Что особенно показательно именно на примере темы нынешней главы - оконной системы X, шрифтовые технологии которой по сию пору оставляют желать лучшего.

Так что пора возвращаться к генеральной линии нынешнего раздела - компьютерным шрифтам вообще и их использованию в Иксах в частности. Существует две формы представления шрифтов на экране - растровая и векторная. В первой форме изображение символа формируется из описания составляющих его точек в виде матрицы пикселей, во второй же - описывается уравнениями специальных кривых, именуемых кривыми Безье. Разумеется, и векторные шрифты выводятся на экран попиксельно - мы ведь помним, что компьютерные дисплеи суть устройства растровые по своей природе). Однако векторная форма представления символов позволяет получать более"гладкие" изображения на мониторах с высоким разрешением, и б) добиваться более качественного вывода на печать (ведь разрешение самого плохого принтера минимум на пол-порядка выше, чем самого лучшего монитора с крутейшей видеокартой.



Очевидно, что растровые шрифты единственно пригодны для применения в чисто текстовом режиме. Теоретически в графической (через Frame Buffer) консоли можно было бы воспроизводить и векторные шрифты, но практически это нигде и никем не реализовано. А вот в Иксах могут быть использованы как растровые, так и векторные шрифты, причем последние - во многих форматах.

Для растровых шрифтов в Иксах обычно применяется формат PCF (Portable Compiled Font). Эти шрифты по своей природе почти немасштабируемы - как и консольные шрифты для текстового режима. Конечно, в графическом режиме символ, образованный матрицей точек, можно в принципе растянуть (или сжать) по вертикали и горизонтали как угодно - но вид его при этом будет варьировать от среднепаршивого до вполне отвратительного. И потому каждая PCF-гарнитура содержит файлы шрифтов с несколькими матрицами точек - собственно, число матриц конкретного шрифта и определяет возможности его масштабирования. Но - не только: наборы растровых шрифтов предназначены для совершенно конкретных разрешений, как правило - 75 и 100 dpi (dot per inch, то есть точек на дюйм - здесь термин разрешение используется в квази-типографском смысле, а не в контексте видеосистемы). Первые используются при экранных (то есть пиксельных) разрешениях вплоть до 800x600, вторые - от 1024x768 и выше.

Важно, что в гарнитурных наборах для растровых шрифтов мы, как правило, не найдем отдельных файлов для шрифтоначертаний. Правда, как мы позже увидим, в большинстве случаев таким шрифтам можно придать полужирное или курсивное начертание, но делается это средствами X-сервера, а не на основе описания собственно шрифтового файла. Соответственно, и результат получается не блестящим...

В Иксах находят себе применение как моноширинные, так и пропорциональные гарнитуры растровой формы воспроизведения. Первые используются главным образом в терминальных окнах, вторые же - для элементов интерфейса, а также вывода текстов в большинстве прикладных программ.

Штатная поставка Иксов в обязательном порядке включает в себя два шрифтовых набора растровых шрифтов общего назначения - с разрешениями 75dpi и 100dpi: именно под такими именами фигурируют содержащие их подкаталоги в сводном шрифтовом каталоге /usr/X11R6/lib/X11/fonts/.


Ни тот, ни другой набор (а в их составе гарнитуры Courier, Helvetica, Times и несколько специальных) символов кириллицы не содержат ни в какой кодировке ее.

Впрочем, дискриминация русскоязычных (и кириллически-ориентированных) пользователей не столь уж выражена: испокон веку в комплекте Иксов есть и набор "нашинских" растровых шрифтов производства фирмы Cronyx, включающий гарнитуры Courier, Fixed (моноширинные), Times и Helvetica (моноширинные) - правда, только для кодировки KOI8-R. Качество их не то чтобы очень высокое, но на первое время сойдет.

Столь же обязательно наличие в комплекте Иксов так называемых misc-шрифтов, которые располагаются в каталоге /usr/X11R6/lib/X11/fonts/misc. Это - чисто моноширинные шрифты единственно гарнитуры (Fixed), которая включает набор шрифтовых файлов с разными матрицами (4x6, 5x7, 6x8 и так далее, вплоть до 10x20) и для разных наборов символов: в числе их, наряду со всеми кодировками ISO8859 (включая ISO8859-5 - ранее это называлось кодировкой ГОСТ для кириллицы), присутствует и KOI8-R. Шрифты misc-fixed предназначены в основном для терминалов, но могут использоваться и в приложениях (например, в текстовых редакторах).

В отечественные дистрибутивы Linux, а также в порты FreeBSD, включены дополнительные растровые шрифты с поддержкой кириллицы. Насколько мне известно, все они представляют собой расширения и улучшения набора Cronyx, выполненные Дмитрием Болховитяниновым, собравшим их в виде пакета cyr-rxf. Пакет этот включает, кроме стандартных гарнитур Times, Helvetica, Courier, дополнительные пропорциональные гарнитуры Lucida и Serene и моноширинные - Lucida Typewriter и Serene Typewriter, правда, только для кодировки KOI8-R. Не смотря на то, что все эти шрифты рассчитаны на разрешение 75 dpi, каждая гарнитура содержит большое количество шрифтовых файлов с разными матрицами (от 8 до 24 точек по вертикали), что позволяет использовать их при высоких разрешениях. И еще одна отличительная особенность пакета - наличие отдельных шрифтовых файлов для разных начертаний - нормального, курсивного и полужирного.



Что касается векторных шрифтов - Иксы, насколько мне известно, поддерживают все распространенные их форматы. Однако практическое значение в наших условиях имеют только Adobe Type 1 и True Type Fonts (TTF) - прочие, типа Speedo, поддержкой кириллицы не обременены. Однако и для Type 1 или TTF кириллических вариантов штатно не предусмотрено. И потому обзаведение ими для использования в Иксах - дело рук самого использователя.

Правда, отечественные дистрибутивы содержат и кириллические шрифты обоих типов, причем - для многих кодировок кириллицы, включая, кроме KOI8-R, также CP1251 и ISO8859-5. В формате Type 1 существует несколько шрифтовых наборов для кодировки KOI8-R. Однако они бедны в отношении гарнитур, качество шрифтов не всегда "на уровне", и лицензионная чистота некоторых из них не вполне ясна.

Наиболее интересны наборы Type1 и TTF, разработанные Валентином Филипповым и распространяемые в составе дистрибутивов Altlinux, но доступные в Сети и сами по себе. Гарнитуры обоих наборов - весьма многочисленны: здесь и гротески Avantgarde, Gothic, Helvetica, Nimbus Sans, и серифы Bookman, Centure Scoolbook, Nimbus Roman, Palatino, Times, и моноширинные гарнитуры Courier и Nimbus Mono. Качество шрифтов весьма высокое - хотя и не всех. Имеются отдельные файлы для различных шрифтоначертаний - нормального, "легкого", полужирного и жирного, курсивного. Шрифты Валентина изначально создавались в кодировке Unicode (UTF8), так что могут быть использованы для передачи любых наборов символов кириллицы (как KOI8, так и CP1251). В общем, учитывая их лицензионную чистоту, - вполне приемлемый выбор.

Однако наибольшее распространение в последнее время получили среди отечественных пользователей юникодные TTF-шрифты, заимствованные из Windows. Малый их джентльменский набор, включающий гарнитуры гротеска Arial, Tahoma, Verdana, сериф Times New Roman, моноширинные Andale и Coutier New, долгое время (видимо, по недосмотру) был доступен свободно на сайте Microsoft. Правда, на условиях распространения только через Сеть (то есть без права на включение в дистрибутивы) и исключительно в первозданном виде - каковой являл собой, понятное дело, cab-архивы.


Теперь с сайта Microsoft эти шрифты исчезли, но явного запрещения на их использование и сетевое распространение, насколько мне известно, так и не последовало. И потому их можно (в виде пакета corefonts) скачать с одного из сайтов, где они имеют место быть, распаковать и юзать в своей POSIX-системе вполне легально. На сей предмет была даже специально придумана утилита cabextract и разработана методика ее применения.

Описывать эту методику не буду: я не настолько наивен, чтобы полагать, будто в наших условиях ею кто-то воспользуется (при наличии более простого способа получения этих шрифтов, на котором не будем акцентировать внимание). Опишу лишь действия, которые потребуются после извлечения шрифтов из их "кабинетов" - они будут общими для всех TTF-шрифтов (а частично и для шрифтовых коллекций вообще).

Как уже говорилось, файлы любого шрифтового набора принято помещать в отдельный каталог внутри каталога /usr/X11R6/lib/X11/fonts/. Поступим так и с извлеченными из cab-архива TTF-шрифтами, создав для них подкаталог corefonts (например). Однако, чтобы Иксы были в состоянии их воспринять, шрифтовой подкаталог должен содержать еще файл fonts.dir и (для масштабируемых векторных шрифтов) fonts.scale. Это - простые списки имен шрифтовых файлов и полного описания соответствующего им шрифтоначертания, например:

Arial.TTF -monotype-Arial-medium-r-normal--0-0-0-0-p-0-koi8-ru

Эту длинную последовательность можно представить в виде подобия базы данных, в которой имя шрифтового файла (в примере - Arial.TTF) выступает в качестве идентификатора записи, а все остальное образовано отдельными полями с дефисом в качестве разделителя. Поскольку тот же формат описания шрифта используется утилитой xfontsel и в так называемых файлах X-ресурсов (речь вскоре дойдет и до того, и до другого), остановимся на смысле отдельных полей подробнее.

Первое поле в терминологии xfontsel носит название fndry - от слова foundry, одно из значений которого - литейная форма (шрифта). А его содержание - это имя фирмы-разработчика, в примере - известного разработчика шрифтов Monotype (то есть можно понимать таr - отлито Монотайпом).


И маленькое отступление для тех, кто не может поступиться принципами. И кому западло использовать что бы то ни было, произведенное в "Империи зла". Так вот, все TTF-шрифты из поставки Windows разработаны именно фирмой Monotype. Более того, гарнитуры Arial, Courier New и Times New Roman - это вариации на тему классических гарнитур Helvetica, Courier и Times, соответственно, которые вообще являются общенародным достоянием, а Tahoma и Verdana созданы Monotype по мотивам гротесков середины прошлого столетия. О происхождении Andale, к сожалению, ничего сказать не могу, но полагаю - и тут ничто не ново под луной. Так что при использовании этих шрифтов поступаться принципами не приходится...

Второе поле нашей "как бы базы" (в xfontsel оно называется fmly, то есть family) - это имя гарнитуры, которую данный шрифтовой файл представляет. Третье (wght - от weight, то есть толщина) - шрифтоначертание в критериях насыщенности, в примере - нормальное (medium), другие возможные значения - "светлое" (light), полужирное (bold), и так далее. В следующем же поле (slant) описывается шрифтоначертание с точки зрения наклона - нормальное (r - от roman) или курсивное (i, o - от italic и oblique, соответственно). За этим следует поле sWdth (set Width), описывающее "компоновку" шрифта - нормальную (normal), как в примере, или сжатую (condensed). Ну а позиция между двумя дефисами - это принадлежность гарнитуры к одному из трех семейств (к традиционным serif и sans serif добавляется decorative); очевидно, что она следует из имени гарнитуры, и потому здесь это поле пустое.

Следующие четыре поля определяют: размер шрифта в пикселях (pxlsz), размер шрифта в "точках" (points, ptsz), разрешение шрифта по горизонтали (resx) и вертикали (resy) в точках на дюйм (dpi). В примере все они заполнены нулями, что свидетельствует о принадлежности рассматриваемого шрифта к категории масштабируемых (таковыми являются все векторные шрифты, как TTF, так и Type 1).


Однако для растровых шрифтов здесь стояли бы соответствующие значения, характеризующие данный шрифтовой файл, например 10-100-75-75. Следующим полем (spc - от spacing) описывается принадлежность к пропорциональному (p) или моноширинному (m) семействам. А затем - поле avgWdth, в котором определяется средняя ширина символа в шрифте. Наконец, в последних двух полях указываются набор символов (rgstry - от registry, и encdng - от encoding) шрифта (например, koi8) и его вариации (например, ru и r - для KOI8-R).

Рассмотренное описание каждого шрифта может показаться несколько запутанным и непонятным (да и на самом деле таковым является; хотя, как мы вскоре увидим, некоторая сермяжная правда в таком формате есть). Тем не менее, это - объективная реальность, данная нам в ощущениях разработчиков Иксов, и с ней приходится считаться. То есть - создать файл fonts.dir в новообразованном каталоге. Благо, для этого существуют утилиты - mkfontdir для шрифтов Type 1 и ttmkfdir - для шрифтов True Type. Правда, в комплект Иксов входит лишь первая - вторая должна быть установлена самостоятельно. Однако использование обеих - элементарно просто: достаточно дать одноименную команду с именем шрифтового каталога в качестве аргумента, в нашем примере это будет выглядеть так:

$ ttmkfdir /usr/X11R6/lib/X11/fonts/corefonts

И получить в результате тот самый файл fonts.dir со всеми его зубодробительными записями, а заодно - и с количеством оных в первой строке (это - обязательный элемент файла, без него X-сервер не сможет построить таблицу доступных шрифтов). Важно также, что для юникодных шрифтов автоматически будут заполнены поля rgstry и encdng - в соответствие с реально доступными в них наборами символов.

Что же касается файла fonts.scale для масштабируемых шрифтов, то его содержание идентично таковому fonts.dir, и его можно создать простым копированием последнего (а также сделать жесткой или символической ссылкой на него).

Теперь остается совсем немногое: внести в секцию Files Иксового конфига строку вида



FontPath "/usr/X11R6/lib/X11/fonts/corefonts/"

и перезапустить X-сервер, чтобы наслаждаться кириллическими TTF-шрифтами. Проследив предварительно, имеет ли место быть в секции Module конфига строка

Load "ttf"

обеспечивающая их поддержку: с некоторых пор это штатная функция X-сервера, тогда как ранее для использования True Type требовались специальные серверы шрифтов (Fonts Server). Использование их не возбраняется и ныне, однако на настольной машине, по моему мнению, лишено смысла. Единственное, что дает Font Server - это возможность загрузки шрифтов с удаленного компьютера, что для пользовательского десктопа не актуально. А вот тормозить работу Иксов сервер шрифтов может вполне...

Теперь нужно только найти способ разбираться с наличным шрифтовым богачеством - выбирать нужные шрифты и устанавливать их. Что касается последнего - для собственно Иксовых приложений это делается либо опциями их командной строки при запуске, либо - в специальных файлах X-ресурсов, о чем речь пойдет в ближайшей интермедии. А вот выбор нужного для установки шрифта возможен на поминаемую выше утилиту xfontsel. Она позволяет через пункты меню, соответствующие описанным ранее полям в файле fonts.dir, выбрать для последних нужные значения (с визуальным контролем результата), а затем, нажатием на кнопку select, скопировать их в буфер. После чего параметры нужного шрифта могут быть либо вставлены в 4командную строку в виде значения соответствующей опции (например, опции -fn), либо вставлены в описание ресурсов приложения в файле типа ~/Xdefaults (см. следующую интермедию).

Выбирать шрифт через меню xfontsel можно в любом порядке. Например, можно сначала через два последних пункта (rgstry и encdng) отфильтровать только шрифты с поддержкой кириллицы, а затем уже определиться с гарнитурой, шрифтоначертанием и размером. Более того, для корректного представления шрифта часто нет нужды в определении всех параметров шрифта: некоторые из них (как, например, размер в пикселях и точках, горизонтальное и вертикальное разрешения) жестко сцеплены друг с другом: выбор размера шрифта 12 пунктов автоматически влечет установку значения 120 в точках.А такие параметры, как семейство гарнитур или их характер (пропорциональный и моноширинный), вообще однозначно вытекают из имени гарнитуры. Хотя шрифты можно фильтровать и по этим признакам: сначала отобрать все моноширинные гарнитуры, пригодные для использования в терминале, а потом уже детализировать свой выбор. Почему я и говорил, что формат описания шрифта содержит в себе некую сермяжную правду...


Варианты конфигурирования


Немедленный запуск свежеустановленных Иксов стопроцентно окончится неудачей: прежде всего их необходимо скорфигурировать - то есть описать в специальном файле параметры аппаратуры - устройств ввода (мыши, клавиатуры) и вывода (видеоадаптера и монитора), а также пути к файлам шрифтов. Файл этот именуется XF86Config (в реализации от XFree86) или xorg.conf (в варианте от Xorg) и местопребыванием своим имеет каталог /etc/X11. Причем в ходе установки Иксов любым способом (из исходников ли, или из бинарников) он сам собой не возникает - перед первым запуском Иксов его необходимо каким-либо способом создать и заполнить должным содержанием.

Способов таких несколько. Первый - написать Иксовый конфиг вручную. Что, при знании формата и смысла опций, в принципе не сложно. Но - долго, скучно и чревато элементарными ошибками. Так что - замнем, для ясности.

Второй способ - сгенерировать конфиг одной из штатных, специально для этого предназначенных утилит. Коих в комплекте также две - xf86config, работающая в диалоговом режиме, и меню-ориентированная xf86cfg, которую можно запустить в графическом (по умолчанию) или текстовом (с опцией -textmode) режиме.

Третий способ - положиться в общем и целом на возможности автоконфигурирования, которые заложены в обеих современных реализациях X-сервера, и с каждой версией становятся все совершеннее.

Наконец, есть и четвертый способ - прибегнуть к одной из фирменных утилит конфигурирования, входящих в комплект ряда user-ориентированных дистрибутивов Linux (Mandrake, Red Hat, вероятно, и других). Но поскольку мы занимаемся настройкой сугубо кросс-платформенной системы, да еще в целях самообразования, воспользоваться им было бы просто неприлично.

Так что, отметя с порога первый и последний способы, мы остались перед простым выбором. При этом, как ни странно, третий способ - автоконфигурирование, - я не стал бы рекомендовать совсем уж начинающему пользователю. Ибо он потребует в дальнейшем ручной доводки, очень несложной, но подразумевающей наличие определенных знаний - причем в одной из самых важных для пользователя сфер, в области локализации, - непременно.
А вот приобрести эти знания проще всего, выполнив один раз конфигурирование с помощью штатной Иксовой утилиты xf86config. Так что с нее мы и начнем - после чего, вооруженные некоторым эмпирическим багажом, обратимся к автоконфигурированию.

Должен предупредить - какой способ, из двух оставшихся, настройки Иксов мы бы ни избрали, без некоторой ручной доводки обойтись все равно не получится.

Итак, запускаем диалоговый конфигуратор Иксов из текстовой консоли:

$ xf86config

Ответом будет сообщение, что

This program will create a basic XF86Config file, based on menu selections you make... ...

и так далее, и последует два предложения:

Press enter to continue, or ctrl-c to abort.

Соглашаемся с первым - ведь это и есть наша цель, не так ли? В награду за смелость нам предложат выбрать мышиный протокол. И хотя вариантов выбора довольно много:

1. Auto 2. SysMouse 3. MouseSystems 4. PS/2 5. Microsoft 6. Busmouse 7. AceCad 8. GlidePoint 9. IntelliMouse 10. Logitech 11. MMHitTab 12. MMSeries 13. MouseMan 14. ThinkingMouse

ломать над ними голову особо не стоит - большая их часть относится к устаревшим или редким сериальным и шинным моделям. А для подавляющего большинства современных (то есть - с интерфейсом PS/2 или USB) подойдет вариант Auto (FreeBSD и DragonFlyBSD он оказывается практически безальтернативным).

Следующий вопрос звучит так:

Please answer the following question with either 'y' or 'n'. Do you want to enable Emulate3Buttons?

Если ваш грызун принадлежит к вымирающему семейств чисто двухкнопочных - следует ответить положительно, средняя кнопка мыши в Иксах работает ничуть не менее активно, чем в текстовой консоли. А эмуляция ее осуществляется одновременным нажатием двух наличных кнопок. Однако если, как это обычно бывает, мышь имеет колесо прокрутки - оно прекрасно справится с функциями средней клавиши, и, соответственно, эмулировать ее нет необходимости.

Ответ на вопрос об файле мышиного устройства

Mouse device:

во FreeBSD (и DragonFlyBSD) также безальтернативен (и должен быть вбит руками):



/dev/sysmouse

Это - виртуальное устройство, подменяющее собой любой из реальных мышиных девайсов - ни один из них под Иксами сосуществовать с драйвером консольной мыши (moused) не может. А в Linux в большинстве случаев проходит умолчальный ответ (/dev/mouse - символическая ссылка на файл всамделишнего устройства, вне зависимости от его интерфейса). Лучше, однако, впечатать руками имя последнего - это будет /dev/psaux для мыши с разъемом PS/2, и /dev/input/mice - для USB-грызунов.

Теперь предстоят ответы на вопросы о клавиатуре. Сначала - определимся с ее типом

Please select one of the following keyboard types that is the better description of your keyboard. If nothing really matches, choose 1 (Generic 101-key PC)

Выбор здесь обширен (около 90 позиций). Но, вопреки предложенному, в большинстве "настольных" случаев (как, впрочем, и ноутбучных) лучше всего подойдут пункты 3

Generic 104-key PC

или 4

Generic 105-key (Intl) PC

Для фирменных клавиш Cherry, Microsoft или Logitech можно попробовать подобрать соответствующие варианты, но, ИМХО, это труда не стоит. А ноутбучные клавиатуры нужно выбирать только в случае полного соответствия реалиям - при неполном лучше избрать один из стандартных настольных вариантов.

Далее следует выбрать раскладку в соответствии, как задумчиво сказано, со страной:

Enter a number to choose the country

Не поленимся пролистать список вплоть до появления России - это важно для русификации (хотя от ручной доводки все равно не избавит):

60 Russian 61 Russian (cyrillic phonetic)

Выбираем 60-й вариант (cyrillic phonetic - штука весьма странная, в стародавние времена применялась на некоторых типах терминалов, ныне - сугубо реликтовая раскладка).

Please enter a variant name for 'ru' layout. Or just press enter for default variant

Теперь предлагается выбрать (точнее, вбить) вариант раскладки. Единственно приемлемый в современных условиях - winkeys, он соответствует фабричной маркировке ныне продаваемых клавиш. Если же нажать Enter для сохранения умолчального варианта - получим раскладку для DOS-маркированных клавиатур, коих сейчас найдешь разве что в музее.



Следующий вопрос -

Please answer the following question with either 'y' or 'n'. Do you want to select additional XKB options (group switcher, group indicator, etc.)?

На него очень важно ответить положительно - это позволит довести русификацию Иксовой клавиатуры почти до ума. А именно - выбрать переключатель раскладок латиница/кириллица из весьма длинного списка:

Group Shift/Lock behavior

1 R-Alt switches group while pressed 2 Left Win-key switches group while pressed 3 Right Win-key switches group while pressed 4 Both Win-keys switch group while pressed 5 Right Alt key changes group 6 Left Alt key changes group 7 Caps Lock key changes group 8 Both Shift keys together change group 9 Both Alt keys together change group 10 Both Ctrl keys together change group 11 Control+Shift changes group 12 Alt+Control changes group 13 Alt+Shift changes group 14 Menu key changes group 15 Left Win-key changes group 16 Right Win-key changes group 17 Left Shift key changes group 18 Right Shift key changes group 19 Left Ctrl key changes group 20 Right Ctrl key changes group

Понимаю, что в столь интимном деле рекомендации неуместны, но мой твердый (и субъективно обоснованный) выбор - 7-й, переключение по нажатию CapsLock (как и в консоли собственно фиксируемое переключение на верхний регистр при этом переходит на комбинацию Shift+CapsLock).

Следующие два вопроса

Third level choosers

и

Control Key Position

я всегда игнорирую (для меня это не актуально). А в ответ на предложение индицировать альтернативную (то есть кириллическую) раскладку

Use keyboard LED to show alternative group

1 Num_Lock LED shows alternative group 2 Caps_Lock LED shows alternative group 3 Scroll_Lock LED shows alternative group

отвечаю второй позицией (Caps_Lock LED), чтобы не путаться, так как Scroll_Lock LED во FreeBSD и DragonFly задействуется в консоли для режима пролистывания буфера экранной истории.

Следующие два вопроса

CapsLock key behavior

и

Alt/Win key behavior

также игнорируем (если у вас, конечно, есть на него осмысленный ответ - отвечайте).


После чего плавно переходим к настройке видеосистемы, нажатием на Enter согласившись с таким предложением

Now we want to set the specifications of the monitor. The two critical parameters are the vertical refresh rate, which is the rate at which the the whole screen is refreshed, and most importantly the horizontal sync rate, which is the rate at which scanlines are displayed.

The valid range for horizontal sync and vertical sync should be documented in the manual of your monitor. If in doubt, check the monitor database /usr/X11R6/lib/X11/doc/Monitors to see if your monitor is there.

Press enter to continue, or ctrl-c to abort.

Правда, предварительно не худо вооружиться документацией на имеющийся в наличии монитор. Потому что ответ на первый же вопрос, о частоте строчной развертки,

You must indicate the horizontal sync range of your monitor.

следует искать именно там. Или, если документация давно потеряна, согласиться с одним из предлагаемых вариантов:

1 31.5; Standard VGA, 640x480 @ 60 Hz 2 31.5 - 35.1; Super VGA, 800x600 @ 56 Hz 3 31.5, 35.5; 8514 Compatible, 1024x768 @ 87 Hz interlaced (no 800x600) 4 31.5, 35.15, 35.5; Super VGA, 1024x768 @ 87 Hz interlaced, 800x600 @ 56 Hz 5 31.5 - 37.9; Extended Super VGA, 800x600 @ 60 Hz, 640x480 @ 72 Hz 6 31.5 - 48.5; Non-Interlaced SVGA, 1024x768 @ 60 Hz, 800x600 @ 72 Hz 7 31.5 - 57.0; High Frequency SVGA, 1024x768 @ 70 Hz 8 31.5 - 64.3; Monitor that can do 1280x1024 @ 60 Hz 9 31.5 - 79.0; Monitor that can do 1280x1024 @ 74 Hz 10 31.5 - 82.0; Monitor that can do 1280x1024 @ 76 Hz 11 Enter your own horizontal sync range

Действуем по старорусскому принципу - лучше перебдеть, то есть занизить частотные характеристики, чем недобдеть, то бишь завысить их. Правда, страшные истории о сгоревших от этого мониторах - в прошлом, и худшее, что грозит при переоценке своей техники - выпадение в черный экран при старте Иксов, но все равно - приятного мало. И в любом случае нужно быть готовым к тому, что даже при строгом следовании спецификации для CRT-монитора идеальной настройки без ручного вмешательства получить не удастся.


А для LCD-панели и этот, и следующий параметр рояля не играют. Потому что следующий вопрос - о частоте кадровой развертки

You must indicate the vertical sync range of your monitor.

предполагающий выбор из

1 50-70 2 50-90 3 50-100 4 40-150 5 Enter your own vertical sync range

также получает ответ из документации.

Далее присваиваем нашему монитору идентификатор - это просто любая последовательность символов, например, наименование его модели. И безусловно положительно отвечаем на вопрос - а хотим ли мы ознакомиться с базой данных видеокарт для выбора подходящей.

Do you want to look at the card database?

База данных эта весьма обширна - более пяти с половиной сотен позиций. Правда, большая часть включенных в нее имен давно ушла в область преданий, а те немногие, что сохранили актуальность, могут выступать под несколькими именами. И для них приемлемы следующие варианты.

Для наиболее, пожалуй, распространенных карт на чипах Nvidia - один из двух (хотя на самом деле это одно и то же):

18 ** NVIDIA (generic) [nv] 349 NVIDIA GeForce GeForce

Для современных карт ATI:

5 ** ATI (generic) [ati]

Для встроенного чипсетного видео от Intel (это также одно и то же):

15 ** Intel i810 (generic) [i810] 291 Intel 810

Для эстетов, сохранивших у себя Matrox от G400 и выше:

17 ** Matrox Graphics (generic) [mga] 319 Matrox Millennium G400 mgag400

Возможно, вам доводилось слышать о фирменных драйверах от производителей видеокарт ATI, Nvidia, Matrox. Так вот, на данной стадии они недоступны: их следует скачивать с фирменных же сайтов и устанавливать в соответствие с прилагаемой к ним документацией. И при этом учитывать, что фирменные драйвера для карт Matrox G400 и выше (но не до Parhellia) действительно способствуют повышению качества изображения. Фирменные же драйвера Nvidia и ATI предназначены только для 3D-акселерации, задействованной лишь в играх. Так что если вы не игроман - никакого выигрыша в двухмерной графике они вам не дадут.

Следом идет вопрос об объеме видеопамяти. Здесь можно отвечать буквально что угодно - все равно в итоговом конфиге эта строка окажется закомментированной.


Хотя аккуратности ради можно поставить и реальное значение.

Теперь задаем идентификатор видеокарты. Также любой - как и идентификатор монитора, он имеет значение только в том случае, если и то, и другое у вас более чем в одном экземпляре (это не шутка - Иксы прекрасно работают в двухмониторных вариантах со всеми картами, такую роскошь поддерживающими - или просто при двух видеокартах). И переходим к настройкам видеорежима. То есть - выбираем наборы и последовательности разрешений для каждой из возможных глубин цветности:

For each depth, a list of modes (resolutions) is defined. The default resolution that the server will start-up with will be the first listed mode that can be supported by the monitor and card. Currently it is set to:

"1280x1024" "1024x768" "800x600" "640x480" for 8-bit "1280x1024" "1024x768" "800x600" "640x480" for 16-bit "1280x1024" "1024x768" "800x600" "640x480" for 24-bit

Modes that cannot be supported due to monitor or clock constraints will be automatically skipped by the server.

1 Change the modes for 8-bit (256 colors) 2 Change the modes for 16-bit (32K/64K colors) 3 Change the modes for 24-bit (24-bit color) 4 The modes are OK, continue.

Набор разрешений не исчерпывается приведенным на экране - он много шире, что можно видеть, если выбрать любой цветовой режим:

Enter your choice: 1

Select modes from the following list:

1 "640x400" 2 "640x480" 3 "800x600" 4 "1024x768" 5 "1280x1024" 6 "320x200" 7 "320x240" 8 "400x300" 9 "1152x864" a "1600x1200" b "1800x1400" c "512x384" d "1400x1050"

Так что остается только сообразоваться со своими потребностями (в разрешении) и возможностями (монитора - видеопамяти в современных картах столько, что они потянут все, что угодно). Следует помнить только о двух вещах: что разрешение, выбранное первым, будет умолчальной для данной глубины цвета, и что мало-мальски комфортная работа в интегрированных средах типа KDE или Xfce начинается с разрешения 1024x768.


А еще: для LCD-дисплеев, как известно, наилучшее качество изображения получается при разрешении, равном физическому количеству пикселей матрицы - так что ниже лучше не устанавливать, а больше не получится (хотя - смотри следующий вопрос). И последнее: разрешение в Иксах можно переключать на лету, причем в обе стороны, посредством клавишных комбинаций: Alt+Control+Серый плюс - в сторону увеличения, и Alt+Control+Серый минус - в сторону уменьшения.

Следующий вопрос весьма интересен:

Please answer the following question with either 'y' or 'n'. Do you want a virtual screen that is larger than the physical screen?

Дело в том, что Иксы поддерживают так называемый виртуальный экран (не путать с виртуальным дисплеем, о котором говорилось ранее) - такой, в котором количество точек по горизонтали и вертикали больше, чем физическое разрешение экрана в пикселях. Визуально это выглядит так, будто рабочий стол тянется за пределы дисплея, смещаясь вслед за движением мыши за его границы. Мне это кажется неудобным - и я на этот вопрос почти всегда отвечаю отрицательно, но некоторым такое нравится. И к тому же может быть полезно при мониторах с маленькой диагональю и на LCD-панелях - при желании получить большее рабочее поле, чем допускает разрешение их матрицы.

Теперь настало время выбрать глубину цвета по умолчанию.

Please specify which color depth you want to use by default:

1 1 bit (monochrome) 2 4 bits (16 colors) 3 8 bits (256 colors) 4 16 bits (65536 colors) 5 24 bits (16 million colors)

Поскольку, как я уже говорил, современные видеокарты допускают любой вариант, думать особенно нечего, 24 бита на пиксель не будет для них обременительным.

Настройка Иксов подошла к концу. Остается только сохранить изменения, ответив положительно на последний вопрос:

I am going to write the XF86Config file now. Make sure you don't accidently overwrite a previously configured one.

Shall I write it to /etc/X11/XF86Config?

Результатом положительного (yes) ответа будет запись всех выбранных параметров в файл /etc/X11/XF86Config (или /etc/X11/xorg.conf) в принятом для него формате.



Вот теперь можно запускать Иксы - для пробы все той же командой

$ X

и если пред глазами предстает экран в серую клеточку с крестообразным, реагирующим на движения мыши, курсором, - процедура завершилась успешно. Конечно, потребуется некоторая правка конфига на предмет обучения его Великому и Могучему (хотя бы в плане печати букв с клавиатуры и вывода их на экран), но об этом я расскажу после попытки самоконфигурирования Иксов (порядок действий будет практически одинаков).

Я надеюсь, что из ответов на вопросы, задаваемые программой xf86config, вы поняли, что она делает (если не совсем - окончательная ясность придет при рассмотрении созданного конфигурационного файла). А также обнаружили один из двух его недостатков: при любой ошибке в ответах на вопросы единственная возможность исправить ее - оборвать выполнение программы (комбинацией Control+C и начать все сначала.

Второй же недостаток - чрезвычайно громоздкий, перегруженный комментариями (большая часть из которых не нужна) конфигурационный файл, генерируемый этой утилитой (и, добавлю, программой xf86cfg - тоже). Разобраться в котором нелегко. В результате же самоконфигурирования создается конфиг маленький и удобопонятный - вот на нем мы и продолжим свои тренировки.

Самоконфигурирование Иксов начинается просто с запуска X-сервера, но - обязательно от лица суперпользователя и с соответствующей опцией (для определенности считаем, что у нас реализация от Xorg версии X11R6.8.2, но с XFree86 все то же самое, с поправкой на имена файлов):

$ Xorg -configure

Впрочем, этим оно и заканчивается: X-сервер выпадет в осадок с сообщением о невозможности сделать то-то и то-то, например, отыскать мышиное устройство. Пугаться этого не следует: перед безвременной кончиной он успевает создать создать прототип своего конфига /root/xorg.conf.new (размером менее 3 Кбайт). Остается только скопировать его куда следует:

$ cp /root/xorg.conf.new /etc/X11/xorg.conf

Теперь можно попробовать запустить Иксы, как это делалось ранее. Если X-сервер встал - все хорошо.


Если нет - разбираемся в причинах, читая, какие ошибки он обнаружил. А поскольку ручная доводка самосгенерированного конфига все равно потребуется, заодно разберемся и с его устройством.

Файл /etc/X11/xorg.conf разбит на несколько секций, каждая заключена в строки

Section "Имя секции" ... EndSection

Рассмотрим их последовательно - тем более, что в файле /etc/X11/XF86Config они будут точно такими же (различия лишь в некоторых строках, которые или очевидны, или будут оговорены явно). Первой идет секция ServerLayout. Содержание ее - указание на генератор конфига (очевидно, зависящий от реализации Иксов):

Identifier "X.org Configured"

и идентификаторы дисплея, мыши и клавиатуры:

Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard"

Поскольку все эти устройства у нас в единственном экземпляре, никаких изменений вносить не потребуется. Вариант двухмониторных конфигураций здесь не рассматривается, а два указательных устройства, обычные на ноутбуках (тачпад и, например, внешняя USB-мышь) в данном случае воспринимается как одно (хотя оба работают нормально).

Следующая секция - Files. В нем перечислены пути к важным для работы Иксов файлам, в частности шрифтовым. И это - первый объект для правки: в списке каталог с кириллическими шрифтами отсутствует, хотя в умолчальном комплекте Иксов таковые (в каталоге /usr/X11R6/lib/X11/fonts/cyrillic/) имеются. Так что вносим соответствующую строку, причем - впереди всех остальных путей к шрифтовым файлам:

FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/"

Конечно, шрифты эти - не верх совершенства, но на первое время сойдет (а вообще разговор об Иксовых шрифтах впереди.

В следующей секции - Module нужно проследить главным образом за наличием строки

Load "ttf"

Это - модуль, обеспечивающий вывод шрифтов True Type - лучше них пока для Иксов ничего не придумали, по крайней мере в отношении кириллической составляющей.


При желании можно избавиться от лишних модулей - например, для поддержки неиспользуемых шрифтов, таких, как speedo (все равно кириллицу они не поддерживают. И хорошо бы добавить строку

Load "freetype"

весьма способствующую качеству рендеринга шрифтов, но - увы - это не всегда проходит.

Далее идет две секции под одинаковым именем InputDevice. Первая по порядку отвечает за клавиатуру, вторая - за мышь, и обе потребуют некоторой правки. Клавиатурная секция в изначальном полуавтоматическом конфиге содержит всего две строки - идентификатор устройства (очевидно - тот же, что и в секции ServerLayout) и имя его драйвера:

Identifier "Keyboard0" Driver "kbd"

Причем (внимание!) вторая строка в XFree86 (и в Xorg версии X11R6.7) выглядит так:

Driver "keyboard"

В любом случае - как можно видеть, ни малейшей возможности ввода кириллицы. И, чтобы ее получить, вписываем опции Xkb - модуля расширенного управления клавиатурой. Он включен по умолчанию, однако при конфигурировании через xf86config неплохо проследить - не слетел ли случайно символ комментария со строки

# Option "XkbDisable"

Опции Xkb определяют а) так называемые правила описания клавиатуры (XkbRules), модель ее (XkbModel), собственно подключаемые раскладки и их варианты (XkbLayout и XkbVariant), а также способ переключения и индикации альтернативной группы (XkbOptions). Все возмозможные варианты их значений можно посмотреть в определенных файлах каталога /usr/X11R6/lib/X11/xkb/ (каких именно - легко определить, например, командой grep). В нашем же случае они таковы:

Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us,ru(winkeys)" Option "XkbOptions" "grp:caps_toggle,grp_led:caps"

С первой строкой понятно (есть еще и другие правила, для иных аппаратных архитектур, но они для нас не интересны). К выбору модели также можно подходить спокойно - pc104 или pc105 подходит почти во всех случаях (в том числе и для ноутбуков, где количество клавиш вроде бы меньше).


В следующей же секции нужно проследить, чтобы имена раскладок были перечислены именно так (и в таком порядке, а вариант winkeys указан именно в скобках после ru - ведь только в этой раскладке он имеет место быть. Обычно подходит также

Option "XkbLayout" "us,ru" Option "XkbVariant" ",winkeys"

где следует обратить внимание на запятую перед winkeys - очевидно, что в раскладке us такого варианта нет.

К слову сказать, при настройке Иксов через xf86config следует позаботиться о приведении соответствующей секции в такой же вид: этот конфигуратор полагает, что раз в нем была выбрана русская раскладка клавиатуры, то необходимости в раскладке us нет, и соответствующая строка имеет вид

Option "XkbLayout" "ru"

в результате чего оказывается возможным ввод только кириллицы, но не латиницы.

Секция InputDevice для мыши также требует некоторого внимания. Во-первых, в нем таится весьма частая причина ошибки при запуске X-сервера, выражающаяся в невозможности найти все то же мышиное устройство. Почему-то при самоконфигурировании в Linux ему часто приписывается имя /dev/mouse, тогда как при использовании файловой системы устройств devfs такого может и не быть. Так что тут нужно, согласившись с наличествующим строками

Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto"

прописать истинное имя файла:

Option "Device" "/dev/input/mice"

А для мышей с колесиком еще и добавить такую строку:

Option "ZAxisMapping" "4 5"

обеспечивающую в современных версиях Иксов скроллинг без всяких дополнительных ухищрений (типа установки программы imwheel, требовавшейся ранее в обязательном порядке).

И, наконец, то, что традиционно считается главным при конфигурировании Иксов (и ранее вызывало наибольшие проблемы) - настройка видеорежима. Тут к автоконфигурированию претензий почти нет: X-сервер при первом старте обычно правильно опознает видеокарту (с точностью до чипа), приписывает ему соответствующий драйвер, и, по крайней мере на LCD-дисплеях, устанавливает разрешение, равное физическому разрешению матрицы и 24-битную глубину цвета.


А частотные характеристики для LCD-дисплея, как уже говорилось, значения не имеют.

Конечно, в секции Device можно кое-что подретушировать, например, включить DRI (Direct Rendering Interface), сняв комментарии со строки соответствующей опции, но это относится уже к поддержке трехмерной графики, нужной почти исключительно для игр.

В итоге путем некоторых обычных манипуляций автосгенерированный конфиг доводится до удовлетворительного состояния, на котором можно и успокоиться. Сравнив только ради интереса его размер с размером конфига, полученного ранее соответствующей утилитой. Что впечатляет - размер последнего около 15 Кбайт, образованных ненужными (и не всегда понятными) комментариями.

Так что в итоге можно констатировать: с точки зрения конечного результата автоконфигурирование Иксов дает ничуть не худший результат, нежели xorg.config (или xf86config), но избавляет от скучной процедуры, позволяет сэкономить время, а в итоге генерирует компактный и, главное, удобопонятный, конфиг. Что же до ручной доводки - она требуется в обоих случаях.


Варианты запуска


Как уже говорилось, Иксы в чистом виде можно загрузить одноименной командой; впрочем, X - это лишь символическая ссылка на имя реального файла X-сервера, XFree86 или Xorg (в зависимости от исполнения), или на т.н. X-wrapper, о котором я скажу потом. Однако мы видели, что ничего доброго из этого не выходит: для использования X-сервера в мирных целях необходим его запуск совместно хотя бы с одной клиентской программой.

Благо, для этого в комплекте Иксов любой реализации существует штатное средство - специальный файл /usr/X11R6/bin/startx. Это обычный сценарий оболочки, описывающий последовательность запуска X-сервера и некоего умолчального X-клиента. А вот каким будет этот X-клиент - от века установлено в файле /usr/X11R6/lib/X11/xinit/xinitrc. По умолчанию этим клиентом является twm - единственный наличный оконный менеджер в комплекте Иксов. Вместе с ним запускается также несколько экземпляров программы xterm, что мы и видим на экране после набора команды startx в строке любой текстовой консоли. Строки, это описывающие, выглядят следующим образом:

# start some nice programs

twm & xclock -geometry 50x50-1+1 & xterm -geometry 80x50+494+51 & xterm -geometry 80x20+494-0 & exec xterm -geometry 80x66+0+0 -name login

Обращаем внимание на символы амперсанда в конце всех строк, кроме последней: это значит, что twm и остальные клиенты работают в фоновом режиме. Последний же экземпляр xterm выступает в качестве своего рода login shell и является программой активной. Выход из него (например, с помощью exit в его командной строке) знаменует собой окончание данного X-сеанса.

При запуске через скрипт startx фигурирующий в нем файл /usr/X11R6/bin/X по умолчанию является символической ссылкой непосредственно на исполняемый файл X-сервера (XFree86 или Xorg), а последний для запуска от лица обычного пользователя должен иметь бит суидности:

lrwxrwxrwx /usr/X11R6/bin/X@ -> XFree86 -rwsr-xr-x /usr/X11R6/bin/XFree86*

Такое решение считается неудовлетворительным с точки зрения безопасности, и поэтому часто для запуска Иксов используется специальная программа - X-wrapper, вызывающая X-сервер опосредованно.
В этом случае последний в бите суидности не нуждается - он устанавливается только на X-wrapper, и /usr/X11R6/bin/X должен симлинком на него. Именно такой способ используется при автоматическом запуске Иксов, как будет показано ниже.

Нужно заметить, что во многих дистрибутивах Linux майнтанеры модифицирует файл /usr/X11R6/lib/X11/xinit/xinitrc по своему усмотрению. В частности, нередко в ответ на команду startx запускается просто X-сервер с единственным терминальным окном. Это - своего рода безлопастный (safe) режим для Иксов: нормально работать при этом затруднительно (ввиду отсутствия средства управления окнами), но вызвать текстовый редактор и поправить файлы конфигурации - можно вполне.

Я уже говорил, что оконных менеджеров для системы X - преизрядное количество, и большая их часть и функционально, и эстетически далеко превосходят штатный twm. Как обеспечить их запуск по умолчанию вместе со стартом Иксов? Напрашивающееся решение - отредактировать /usr/X11R6/lib/X11/xinit/xinitrc, - не всегда удобно (так как требует прав суперпользователя) и вообще идеологически неправильно. Потому что штатным средством является создание соответствующего пользовательского dot-файла - ~/.xinitrc. В простейшем случае в него достаточно внести строку вроде

exec fluxbox

где вместо fluxbox вписать имя файла, запускающего любимый оконный менеджер или интегрированный десктоп (который,разумеется, сначала должен быть установлен в системе). При желании запускать вместе с ним еще какие-либо приложения (терминальные окна, утилиты мониторинга системы и т.д.), имена их исполняемых файлов можно поместить в ~/.xinitrc отдельными строками - до или после строки, запускающей оконный менеджер. Важно только, чтобы все строки, кроме последней, заканчивались символом амперсанда (обязывающего к фоновому исполнению соответствующей задачи).

Однако предварительно нужно этот самый. любимый. менеджер окон выбрать. В следующей главе я дам кое-какую информацию, которая, надеюсь, в этом деле поможет. Однако сделать окончательный выбор без собственного впечатления невозможно.


А чтобы получить впечатление - нужно перепробовать их изрядное количество.

На вопросах установки оконных менеджеров здесь останавливаться неуместно - это делается либо штатными средствами управления пакетами данной ОС или дистрибутива, либо - обычным порядком, компиляцией из исходников - не забывая только эти самые исходники сохранять, на предмет последующей деинсталляции. Так что поговорим только о средствах запуска оконных менеджеров, уже установленных.

Самый простой способ - это вписать все их имена построчно, закрыв символами комментария, в файл ~/.xinitrc. И запускать по очереди, снимая ремарки с интересующего в данный момент. Нужно только учесть, что некоторые из оконных менеджеров не то чтобы требуют предварительного конфигурирования, но настоятельно проявляют такое желание - примером является WindowMaker. При этом происходит перезапись имеющегося файла ~/.xinitrc, в расчете на запуск именно сконфигурированной программы управления окнами (хотя старая копия стартового конфига и сохраняется под другим именем).

Другой способ - это все же отредактировать /usr/X11R6/lib/X11/xinit/xinitrc таким образом, чтобы в качестве умолчального X-клиента запускалось лишь одно терминальное окно:

xterm

А уж из его командной строки запускать подлежащий изучению менеджер окон. При этом возможно, оказывается, запустить несколько X-сессий - каждую со своим менеджером окон, стартующим из командной строки эмулятора терминала.

Для запуска нескольких X-сессий одного и того же X-сервера следует вспомнить о понятии виртуального дисплея. X-сервер, запущенный первым, стартует на нулевом дисплее, который соответствует ближайшей доступной и свободной (то есть неактивизированной процессом типа getty) виртуальной консоли. И попытка дать команду startx (или просто X) повторно - с другого виртуального терминала, - выведет сообщение о том, что дисплей занят (и, соответственно, о невозможности связи с ним X-сервера). Чтобы этого не случилось, номер дисплея (начиная с 1) для второй сессии Иксов (всех последующих) следует задать явно:



startx -- :1

Здесь следует не забыть про удвоение символов дефиса --, знаменующее окончание списка аргументов (возможных X-клиентов и относящихся к ним опций). Теоретически указание на номер виртуального дисплея следует предварить номером дисплея физического, в форме

startx -- 0:1

но практически для персоналки в обычной конфигурации его можно опустить. Опять-таки теоретически, как говорилось ранее, можно открыть до 231 самостоятельных X-сессий, но практически, думаю, лимит оперативной памяти будет исчерпан много раньше: каждая сессия требует для себя 16 Мбайт суммарной (RAM+swap) памяти, из которых 4 Мбайт приходится на память физическую; и немало памяти отъест еще и оконный менеджер и, особенно, интегрированная среда типа KDE или Gnome.

В реальных условиях запуск нескольких X-сессий на пользовательском десктопе имеет смысл только в целях экспериментирования с оконными менеджерами или каких-то специальных случаях (хотя каких именно - ума не приложу). Дело в том, что, в отличие от виртуальных консолей, обмен данными между X-сессиями невозможен (по крайней мере, я такого способа не нашел ни в ходе практических попыток, ни в документации). Так что запуск дополнительного сеанса Иксов ничего не прибавит нам в плане расширения рабочего пространства. Да его и так вдоволь - все современные оконные менеджеры, в дополнение к экранам с виртуальными разрешениями (это - функция самого X-сервера) поддерживают большое количество так называемых виртуальных рабочих столов, на каждом из которых может быть открыто практически неограниченное количество окон.

В случае, если основная работа пользователя проходит в графическом режиме, возникает естественное желание - обеспечить его старт при загрузке машины. В Linux это обычно делается очень просто: нужно только открыть файл /etc/inittab, посмотреть в начале его перечень runlevels:

# Runlevels: # 0 Halt # 1(S) Single-user # 2 Not used # 3 Multi-user # 4 Not used # 5 X11 # 6 Reboot

определить, какой из них соответствует в данном дистрибутиве старту в графическом режиме (в примере, относящемся к Archlinux, - 5-й), и назначить его умолчальным, изменив строку



id:3:initdefault:

таким образом:

id:5:initdefault:

Никаких дополнительных телодвижений, скорее всего, не потребуется: после перезагрузки машины перед глазами предстанет, вместо первой виртуальной консоли с предложением к авторизации, т.н. графический менеджер входа в систему - по умолчанию им будет xdm из штатного Иксового комплекта. Достаточно набрать учетное имя своего акаунта и пароль доступа - и пользователь оказывается внутри X-сессии. Под соответствующий ей X-дисплей будет задействована первая же свободная виртуальная консоль - в большинстве дистрибутивов 7-я. В отличие от X-сессии, запущенной вручную, управляющего терминала у нее не будет, все прочие виртуальные консоли остаются девственно чистыми.

Во FreeBSD и DragonFlyBSD дело обстоит ничуть не сложнее: открывается файл /etc/ttys, в нем отыскивается имеющаяся по умолчанию строка

ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure

и в ней значение off четвертом поле заменяется на on, послед чего выполняется рестарт машины - с тем же результатом, что и в Linux.

В любом случае важно только проследить, чтобы X при этом был ссылкой на программу-враппер, а файл последней имел бы бит суидности:

lrwxr-xr-x /usr/X11R6/bin/X@ -> /usr/X11R6/bin/Xwrapper-4 -r-sr-xr-x /usr/X11R6/bin/Xwrapper-4*

Прервать такую автоматом запущенную X-сессию, то есть перезагрузить X-сервер (например, при изменении его настроек) можно - клавишами Alt+Control+Backspace или штатными средствами запущенного клиента, - но это вызовет лишь возобновление приглашения xdm. Полностью избавиться от графического режима можно только возвратом общесистемных конфигов (/etc/inittab или /etc/ttys) в исходное состояние.

Авторизовавшись в панели xdm, пользователь оказывается в X-сессии, но - не совсем в своем привычном и настроенном (через ~/.xinitrc) окружении. Ибо при автоматическом старте Иксов отработки сценария xinit (и, соответственно, считывания конфигов xinitrc и ~/.xinitrc не производится. оно будет определяться умолчаниями общесистемного xinitrc.Чтобы обеспечить запуск своего любимого оконного менеджера и сопутствующих ему программ (то, что при команде startx загружается из "домашнего" ~/.xinitrc), необходимо иметь файл ~/.xsession. Для начала его можно сделать идентичным ~/.xinitrc, ограничившись строкой с именем оконного менеджера, а дальше - сами разберетесь.

Для графической авторизации можно использовать и другие менеджеры входа в систему - например, kdm из комплекта KDE, или gdm, входящий в состав GNOME. По сравнению в xdm они предоставляют множество дополнительных возможностей. Правда, и требуют немало - соответствующих интегрированных сред в установленном виде.