Разработка приложений в среде Linux. Второе издание

Одним из проектов, повлиявших на эту совместимость, является стандарт иерархии файловых систем (Filesystem Hierarchy Standard — FHS), ранее называемый стандартом файловых систем Linux (Linux Filesystem Standard — FSSTND), определяющий, где следует хранить множество файлов, и объясняющий в общих чертах, каким образом должна быть организована оставшаяся часть файловой системы. Позднее проект под названием стандартная база Linux (Linux Standard Base — LSB) был расширен без учета структуры файловой системы, определяя программные интерфейсы приложений (Application Programming Interface — API) и двоичные интерфейсы приложений (Application Binary Interface — ABI). Эти интерфейсы предназначены для возможности компиляции приложения один раз и развертывания его на любой системе, подчиняющейся определению LSB для данной архитектуры процессора. Эти и другие документы доступны на Web-сайте по адресу http://freestandards.org.

1.3. Важные факты в создании систем Unix

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

На заре восьмидесятых годов прошлого столетия разработчики Unix были разделены на два "лагеря": первый — Калифорнийский университет в Беркли, а второй — компания AT&T Bell Laboratories. Оба учреждения разрабатывали и поддерживали операционные системы Unix, которые происходили от исходной реализации Unix, созданной в Bell Laboratories.

Версия Unix от Беркли стала известной как программный дистрибутив Беркли (Berkeley Software Distribution — BSD) и приобрела популярность в научном сообществе. Система BSD впервые включила организацию сетей TCP/IP, что повлияло на ее успех и помогло убедить компанию Sun Microsystems основать на BSD первую операционную систему Sun — SunOS.

В компании Bell Laboratories также трудились над совершенствованием Unix, но, к сожалению, несколько другими способами, чем в Беркли. Разнообразные выпуски Bell Laboratories обозначались словом "System", сопровождаемым римским числом. Окончательным выпуском Unix от Bell Laboratories была System V (или SysV); UNIX System У Release 4 (SVR4) сегодня предоставляет кодовую базу для большинства коммерческих операционных систем Unix. Стандартным документом, описывающим System V, является System V Interface Definition (SVID).

Эта разветвленная разработка Unix значительно разнообразила системные вызовы, системные библиотеки и основные команды систем Unix. Одним из лучших примеров такого расщепления являются сетевые интерфейсы, сопровождающие приложения каждой операционной системы. Системы BSD использовали интерфейс под названием сокетов, позволяющий программам сообщаться друг с другом по сети. С другой стороны, System V предоставила интерфейс транспортного уровня (Transport Layer Interface — TLI), полностью несовместимый с сокетами, и официально определенный транспортный интерфейс X/Open (X/Open Transport Interface — XTI). Такая разнородная разработка значительно снизила переносимость программ между версиями Unix, увеличивая стоимость и уменьшая доступность сторонних продуктов для всех версий Unix.

Еще одним примером несовместимости систем Unix является команда ps, позволяющая запрашивать информацию о процессах операционной системы. В системах BSD команда ps aux выдает полный листинг всех процессов, работающих на машине; в System V эта команда недопустима, вместо нее необходимо использовать ps -ef. Форматы вывода так же несовместимы, как и аргументы командной строки. (Команда ps в Linux пытается поддерживать оба стиля.)

Пытаясь стандартизовать все аспекты Unix, которые разошлись из-за разных подходов к разработке в этот период (это еще известно как "войны Unix"), индустрия Unix спонсировала создание набора стандартов, которые определяют предоставляемые Unix интерфейсы. Часть стандартов, имеющая дело с интерфейсами программных и системных инструментов, была названа POSIX (технически это серия IEEE Std 1003, составленная из многих отдельных и черновых стандартов) и выпущена Институтом инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers — IEEE).

Однако исходные серии стандартов POSIX были не полностью завершены. Например, основные концепции UNIX вроде процессов считались необязательными. Более полный стандарт прошел через несколько версий и названий (например, серия стандартов руководства по переносимости X/Open (X/Open Portability Guide — XPG)) перед тем, как был переименован в одиночную спецификацию Unix (Single Unix Specification — SUS), выпущенную The Open Group (владельцем торговой марки UNIX). SUS после нескольких пересмотров была принята IEEE как самая новая версия стандарта POSIX, в настоящее время это IEEE Std 1003.1-2004 [25], и время от времени обновлялась несколькими поправками. IEEE Std 1003.1-2003 был также принят в качестве стандарта ISO/IEC 9945-2003. Самую новую онлайновую версию этого стандарта можно найти по адресу http://www.unixsystems.org/.

Более ранние стандарты, на основе которых был создан этот обновленный унифицированный стандарт, включают все ранние стандарты IEEE Std 1003.1 (POSIX.1 — программный интерфейс С), IEEE Std 1003.2 (POSIX.2 — интерфейс оболочки), а также все связанные стандарты POSIX наподобие расширений реального времени, определенных как POSIX.4, которые позже были переименованы в POSIX.1b, и несколько черновых стандартов.

Поскольку "POSIX" и "SUS" теперь являются синонимами, на комбинированную работу в этой книге мы будем ссылаться как на POSIX.

1.4. Происхождение Linux

"Широта выбора — самое лучшее качество, присущее стандартам".[1] К услугам разработчиков Linux была двадцатилетняя история Unix, но более важным является то, что справочными материалами им служили высококачественные стандарты. Изначально Linux разрабатывался в соответствии с POSIX; там, где не было POSIX, Linux следовала практике System V, за исключением организации сетей, где и системные вызовы, и организация сетей придерживались намного более популярной модели BSD. Теперь, когда существует объединенный стандарт SUS/POSIX, дальнейшее развитие обычно совместимо с более новым стандартом POSIX, а прошлые отклонения от него по возможности откорректированы.

Самым существенным отличием между SVR4 и Linux с точки зрения программирования является то, что Linux не предоставляет столько же дублированных программных интерфейсов. Например, даже программисты, занимавшиеся написанием кода исключительно для систем SVR4, предпочитали сокеты Беркли интерфейсу транспортного уровня (TLI) из SysV; Linux избегает накладных расходов TLI и предоставляет только сокеты.

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

Глава 2

Лицензии и авторские права

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

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

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

2.1. Авторское право

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

Бернское соглашение об авторском праве (http://www.wipo.org), международный договор о соглашениях об авторском праве и смежных правах, требует от стран-участниц придавать авторским правам законную силу только в случае:

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

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

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

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

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

2.2. Лицензирование

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

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

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

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

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

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

2.3. Лицензии на свободное ПО

Как описывалось в главе 1, термин открытый исходный код (Open Source) был создан как результат попытки разрешить споры вокруг слов "свободный" и "открытый" (free) в словосочетании "свободное ПО" ("free software"). Для управления понятием "открытый исходный код" была создана Инициатива открытого исходного кода (Open source Initiative — OSI) и, несмотря на то, что ее попытки зарегистрировать торговую марку термина (для защиты его значения) были отклонены Службой патентов и торговых знаков США (US Patent and Trademark Office), OSI получила в свое распоряжение знак сертификации "свободное ПО, сертифицированное OSI". (Законных ограничений на использование термина открытый исходный код не существует, но они существуют относительно знака сертификации "свободное ПО, сертифицированное OSI".)

OSI поддерживает определение открытого исходного кода (Open Source Definition — OSD) — описание прав, предоставляемое лицензиями открытого исходного кода; она также поддерживает полный список сертифицированных ею лицензий, чтобы удовлетворить запросы OSD, среди которых — доступность исходного кода, отсутствие ограничений на свободное распространение продукта, разрешение производных работ, а также запрет дискриминации лиц, групп или областей для попыток. Полное OSD вместе со списком лицензий, сертифицированных как "свободное ПО, сертифицированное OSI", доступно на сайте http://opensource.org/.

2.3.1. Общедоступная лицензия GNU

GPL является одной из самых ограничивающих лицензий свободного ПО. Если вы включаете исходный код, лицензированный GPL в другой программе, к этой программе при лицензировании также должны быть применены условия GPL[2]. В Фонде свободного программного обеспечения (FSF, автор GPL) считают, что выполнение связывания с помощью библиотеки "создает производную работу"; другие трактуют ее как "работу простого агрегирования". Поэтому в FSF утверждают, что вам нельзя выполнять компоновку с библиотекой, к которой применены условия GPL, если к компонуемой программе не применяется лицензия GPL. Однако некоторые лица придерживаются мнения, что связывание — это "простое агрегирование", тогда как GPL утверждает следующее.

Кроме того, простое агрегирование другой работы, не основанной на Программе, с Программой (или с работой, основанной на Программе) с помощью тома внешней памяти либо носителя дистрибутива не помещает другую работу в область действия данной Лицензии.

Если вы рассматриваете исполняемый файл как "том внешней памяти", можете прибегнуть к полному агрегированию.

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

2.3.2. Общедоступная лицензия библиотеки GNU

Общедоступная библиотечная лицензия GNU (GNU Library General Public Licence — LGPL) предназначена для увеличения общей полезности библиотек. Цель LGPL — разрешить пользователям обновлять или улучшать свои библиотеки без необходимости получения новых версий программ, компонуемых с этими библиотеками. С этой целью LGPL не пытается установить какие-то лицензионные ограничения на программы, компонуемые с библиотекой, до тех пор, пока эти программы скомпонованы с совместно используемыми версиями библиотек, к которым применены условия LGPL, или которые снабжены объектными файлами для приложения, позволяя пользователю заново связывать приложение с новыми либо усовершенствованными версиями библиотеки.

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

К очень немногим библиотекам применены условия GPL; большинство из них подпадает под действие LGPL. Библиотеки, подчиняющиеся GPL, обычно трактуются в соответствие с LGPL, поскольку авторы библиотек не были в курсе либо не приняли во внимание существование LGPL. В ответ на вежливую просьбу многие авторы обновляют лицензию своих библиотек, применяя к ним условия LGPL.

2.3.3. Лицензии стиля MIT/X/BSD

Лицензии стиля MIT/X намного проще, чем GPL или LGPL; их единственным ограничением является (если по простому) поддержка всех существующих уведомлений об авторских правах и лицензионных условий в исходном либо двоичном распространении, и запрет использования имени любого автора без его письменного соглашения в целях подтверждения либо продвижения производных работ.

2.3.4. Лицензии старого стиля BSD

Лицензии старого стиля BSD добавляют к условиям лицензий MIT/X существенное ограничение, которое состоит в том, что рекламные материалы, упоминающие свойства ПО, включают подтверждение. Сама лицензия BSD была изменена с целью устранения этого ограничения, но некоторое ПО продолжает пользоваться лицензиями, смоделированными по старой лицензии BSD.

2.3.5. Лицензия Artistic License

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

2.3.6. Несовместимости лицензий

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

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

Если вы работаете с кодом, к которому применена лицензия GPL или LGPL, вы не сможете включить его в код, к которому применены условия лицензии стиля раннего BSD, поскольку GPL и LGPL запрещают "дополнительные ограничения", а старая лицензия BSD содержит дополнительные ограничения (не учитывающие ограничения GPL или LGPL) касательно рекламы и поддержки. По причине этого конфликта к некоторым элементам ПО применены альтернативные условия — условия и GPL, и лицензии раннего стиля BSD; у вас есть право выбора, каких лицензионных условий придерживаться.

Если код, к которому применены условия GPL или LGPL, включен в работу, производную от лицензии стиля BSD/MIT/X, ко всей производной работе (для всех практических целей) должны быть применены условия GPL либо LGPL соответственно.

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

Глава 3

Онлайновая системная документация

Web-сайт, посвященный этой книге и доступный по адресу http://ladweb.net, содержит дополнения к тексту книги, детальную информацию по темам, выходящим за рамки книги, и ссылки на дополнительные сведения в Internet.

3.1. Оперативные страницы руководства

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

Доступ к оперативным страницам руководства предоставляется тремя программами. Программа man отображает отдельные оперативные страницы руководства, а команды apropos и whatis ищут ключевые слова в наборе оперативных страниц руководства. Команды apropos и whatis производят поиск в одной и той же базе данных; различие состоит в том, что whatis отображает только строки, в точности соответствующие слову, которое вы ищете, a apropos отображает любую строку, содержащую слово, которое вы ищете. К примеру, если вы ищете man, apropos отобразит manager и manipulation, в то время как whatis отобразит лишь слово man, отделенное от других букв пробелом либо знаком пунктуации, например, man.config. Попробуйте запустить команды whatis man и apropos man, чтобы увидеть разницу.

Многие оперативные страницы руководства в Linux являются частью большого пакета, собранного процессором лингвистической информации (language data processor — LDP). А именно, страницы разделов 2 (системные вызовы), 3 (библиотеки), 4 (специальные файлы или файлы устройств) и 5 (форматы файлов) принадлежат в основном к коллекции оперативных страниц руководства LDP и являются наиболее полезными в программировании. Если необходимо выяснить, какой раздел следует просмотреть, укажите номер этого раздела перед названием оперативной страницы руководства, которую вы намереваетесь просмотреть.

Например, man man предоставляет оперативную страницу руководства для команды man из раздела 1; если вы хотите просмотреть спецификацию о написании оперативных страниц руководства, укажите раздел 7 — man 7 man.

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

Также обратите особое внимание на то, что оперативные страницы руководства библиотеки поддерживаются отдельно от самой библиотеки С. Поскольку библиотека С обычно не меняет своего поведения, это не является проблемой. Все дистрибутивы Linux теперь используют библиотеку GNU С, которая рассматривается в главе 6. К библиотеке GNU С прилагается полная документация. Эта информация доступна в форме Texinfo.

3.2. Информационные страницы

В проекте GNU для представления документации был принят формат Texinfo. Документацию Texinfo можно распечатать (используя преобразование в ТЕХ) либо прочитать в онлайне (в формате "info", очень раннем гипертекстовом формате, предшествующем World Wide Web). В Linux существует множество программ для чтения информационной документации. Ниже приведен небольшой перечень.

• В редакторе Emacs есть режим чтения информации; наберите <ESC> X info для входа в этот режим.

• Программы info и pinfо являются небольшими программами текстового режима для быстрого просмотра информационных страниц.

• Большинство программ системной документации (например, программы yelp от GNOME и khelpcenter от KDE) могут отображать информационные страницы. Мы рекомендуем эти инструменты, поскольку они предоставляют гипертекстовый интерфейс к информационным страницам, более знакомый всем, кто умеет использовать Web-браузер, чем интерфейс, предоставляемый Emacs, info или pinfо. (Эти инструменты также предлагают другую системную документацию, например, оперативные страницы руководства и документацию по системе, частью которой они являются.)

3.3. Прочая документация

Каталог /usr/share/doc представляет собой всеохватывающее место для несобранной иными способами документации. Большинство пакетов, установленных в вашей системе, инсталлируют внутри каталога /usr/share/doc файлы "README", документацию в разных форматах (включая простой текст, PostScript, PDF и HTML) и примеры. У каждого пакета имеется свой собственный каталог, носящий имя этого пакета и номер его версии.

Часть II

Инструментальные средства и среда разработки

Глава 4

Инструментальные средства разработки

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

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

Если вы уже знакомы с Emacs, vi, make, gdb, strace и ltrace, в этой главе ничего нового вы для себя не найдете. Тем не менее, в оставшейся части книги предполагаются хорошие знания какого-нибудь текстового редактора. Практически весь свободный исходный код Unix и Linux собирается при помощи make, a gdb — один из самых распространенных отладчиков, доступных для Linux и Unix. Утилита strace (или подобная утилита под названием trace либо truss) доступна в большинстве систем Unix; утилита ltrace была изначально написана для Linux и в большинстве систем недоступна (на момент написания книги).

Однако не стоит думать, что для Linux нет графических средств разработки; на самом деле, все как раз наоборот. Этих средств огромное количество.

На момент написания этой книги привлекали внимание две интегрированных среды разработки (Integrated Development Environment — IDE), которые могут входить в используемый вами дистрибутив: KDevelop (http://kdevelop.org/), часть среды рабочего стола KDE, и Eclipse (http://eclipse.org/), межплатформенная среда, основанная на Java, которая первоначально, была разработана IBM, а теперь поддерживается крупным консорциумом. Однако в этой книге мы не будем останавливаться на рассмотрении упомянутых сред, поскольку они сопровождаются детальной документацией.

Даже несмотря на то, что для работы в Linux доступны многочисленные IDE, они пользуются не такой популярностью, как на других платформах. Даже если среда IDE применяется, все же более практичным считается написание программного обеспечения с открытым исходным кодом без ее задействования. Все это делается для того, чтобы другие программисты, которые захотят сделать свой вклад в ваш проект, не были стеснены вашим выбором IDE. Среда KDevelop поможет собрать проект, который будет использовать стандартные инструменты Automake, Autoconf и Libtool, используемые в многочисленных проектах с открытым исходным кодом.

Сами по себе стандартные средства Automake, Autoconf и Libtool играют важную роль в процессе разработки. Они были созданы для помощи в построений приложений таким образом, чтоб эти приложения могли быть почти автоматически перенесены в другие операционные системы. Ввиду того, что эти средства сложны, в настоящей книге мы рассматривать их не будем. Кроме того, эти средства регулярно изменяются; электронные версии GNU Autoconf, Automake и Libtool [41] доступны по адресу http://sources.redhat.com/autobook/.

4.1. Редакторы

Разработчики Unix традиционно придерживались строгих и разнотипных предпочтений особенно в выборе редакторов.

Доступно множество редакторов, которые легко изучить самостоятельно; наиболее распространенными можно считать vi и Emacs. Оба редактора являются мощными представителями своего типа, чего не скажешь на первый взгляд. У обоих редакторов сравнительно крутая кривая обучения, и они радикально отличаются друг от друга. Emacs является достаточно крупным; он сам себе операционная среда, vi не занимает много места и разработан специально для внедрения в среду Unix. Было написано множество клонов и альтернативных версий каждого редактора, и у самих версий также имеются свои клоны.

В этой книге мы не будем углубляться в изучение vi и Emacs, поскольку материал занял бы слишком много места. В [32] каждому редактору посвящены отдельные главы, кроме того, рекомендуем обратиться к [5] и [17]. В нашей книге мы только сравним Emacs и vi и расскажем, как получить оперативную справку по каждому из них.

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

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

Оба редактора позволяют создавать макросы для упрощения работы, но их макроязыки очень сильно отличаются. Emacs включает в себя целый язык программирования под названием elisp (Emacs Lisp), который очень тесно связан с языком программирования Common Lisp. В первоначальном варианте vi встроен более спартанский язык, ориентированный на стек. Большинство пользователей просто связывают с клавишами простые однострочные команды vi, но эти команды зачастую запускают программы за пределами vi, чтобы управлять данными внутри vi. По Emacs Lisp написано огромное руководство, включающее пособие по использованию; по языку, встроенному в vi, документация сравнительно скупа.

Некоторые редакторы позволяют смешивать и совмещать функциональности. Так, существуют редакторы, в которых можно использовать Emacs в режиме vi (viper), позволяющем использование стандартных команд vi; в другом клоне vi под названием vile ("vi like Emacs") можно использовать vi в режиме Emacs.

4.1.1. Emacs

Emacs встречается в нескольких вариациях. Первоначальный редактор Emacs был написан Ричардом Столлманом (Richard Stallman), одним из лидеров Фонда свободного ПО (Free Software Foundation — FSF). В течение многих лет его GNU Emacs был самым популярным редактором. С недавних пор популярностью начал пользоваться другой вариант GNU Emacs — XEmacs, в котором больше места уделяется поддержке графического интерфейса. XEmacs начал свою жизнь в качестве Lucid Emacs, набора расширений GNU Emacs, разработанного теперь уже распавшейся компанией Lucid Technologies. В намерения этой компании входило официально включить XEmacs в GNU Emacs. Но из-за технических различий команды не смогли слить свои коды. Несмотря ни на что, эти два редактора отлично совмещаются, а программисты обоих команд заимствуют коды друг у друга. Ввиду того, что обе эти версии очень похожи, в дальнейшем мы будем ссылаться на них как на Emacs.

Лучший способ для удобной работы с редактором Emacs — изучить пособие по работе с ним. Запустите emacs и наберите ^ht. Наберите ^x^c для выхода из Emacs. С помощью обучающей программы можно узнать, где получить дополнительную информацию по Emacs. Здесь вы не узнаете, как получить руководство по Emacs, распространяемое вместе с самим редактором. Для вызова этого руководства наберите ^hi.

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

4.1.2. vi

Если вы быстро набираете текст и хотите, чтоб ваши пальцы находились в правильном положении[3], vi вам наверняка понравится, поскольку его набор команд был разработан таким образом, чтобы движений пальцев печатающего было как можно меньше. Этот редактор также ориентирован на пользователей Unix. Если вы знакомы с sed или awk либо другими программами Unix, использующими стандартные регулярные выражения с ^ для перехода к началу строки и $ для перехода к ее концу, работа с vi покажется вам простой и естественной.

К сожалению, освоение vi может оказаться более сложным, нежели Emacs. Дело в том, что хоть пособия по vi подобны учебникам по Emacs, ни в одной версии vi нет стандартного способа запуска учебного пособия. Тем не менее, многие версии, включая версию, поставляемую с обычными дистрибутивами Linux, поддерживают команду :help.

В наиболее общей версии vi, vim ("Vi IMproved"), есть множество интегрированных средств из набора разработки Emacs, включая выделение синтаксиса, автоматическое расположение текста, язык написания сценариев и разбор ошибок компилятора.