Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 637 сообщений
Cообщения с меткой

unix - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] Семантический перенос строк

Вторник, 09 Августа 2016 г. 10:11 (ссылка)

От переводчика:



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



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



Хочу предупредить, что не все ссылки в статье работоспособны, но я решил оставить их как есть — мало ли что.



Итак, статья.



Семантический перенос строк



На ежегодном ликбезе по Sphinx проводимом в рамках PyCon я регулярно даю один совет. Благодарный слушатель спросил, где я сам почерпнул эти знания. Я провел археологические изыскания и теперь у меня есть ответ на этот вопрос. Позвольте рассказать вам про “семантические переносы строк”, а потом я открою источник этого знания — которое, как выясняется, было явлено миру когда мне было всего несколько месяцев от роду!



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



Результат может оказаться замечательным.



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



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



-Великолепие решения в том, что теперь, если вы
-передумаете насчёт того, как должен выглядеть
-параграф можно изменить форматирование вывода
-простым изменением определения ‘‘.PP’’ и
-перезапуском форматтера.
+Красота решения в том, что теперь, если вы
+передумаете насчёт того, как должен выглядеть
+параграф можно изменить форматирование вывода
+простым изменением определения ‘‘.PP’’ и
+перезапуском форматтера.


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



-Великолепие решения в том,
+Красота решения в том,
что теперь, если вы передумаете насчёт того,
как должен выглядеть параграф
можно изменить форматирование вывода
простым изменением определения ‘‘.PP’’
и перезапуском форматтера.


“Семантические переносы строк,” как я их называю, облегчают мне жизнь уже более двадцати лет, и диктуют устройство моих текстовых файлов под капотом независимо от используемой разметки, будь то HTML, TeX, RST, или почтенный troff .



Откуда же я узнал об этой штуке?



Долгое время я думал, что моим источником было Руководство по инструментарию для созданию UNIX документации. Инструментарий был попыткой AT&T продвинуть на рынок операционную систему, которая стала культовой среди инженеров Bell Labs, путем добавления в систему мощнейших инструментов по офомлению текста. Попытка конечно провалилась — говорят, что в AT&T с маркетингом всё было просто ужасно, также как и в Xerox, где понятия не имели что делать с идеями бурлившими в PARC в 1970-x — но мой отец работал в Bell Labs и у него дома был экземпляр документации к Инструментарию. (В интернете я копии найти не смог — может быть, все доступные копии были уничтожены во время разрушительной войны за копирайт которая совершенно заслуженно привела SCO к краху?)



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



Он опубликовал “UNIX для начинающих” в качестве технического меморандума Bell Labs 74-1273-18 29 октября 1974 года. В нём описана гораздо более простая версия операционной системы, чем в его более известной и широкодоступной “UNIX для начинающих — Второе Издание” 1978 года. В результате долгих поисков я обнаружил одинокую копию, ссылка на которую приведена выше, размещённую на малоизвестном японском сайте, посвящённом UNIX 6th Edition. В разделе “Советы по подготовке документов” Керниган делится своей мудростью:



Советы по подготовке документов



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



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



— Брайен В. Керниган, 1974


Заметьте, как питонически звучит его совет — он заменяет выдумки о документах написанных “раз-и-навсегда” реалистичным подходом — написанием текста, который просто редактировать в дальнейшем.



Я, должно быть, прочитал это когда впервые изучал UNIX и пронёс сквозь все эти годы. Тот факт, что совет данный в 1974, и изначально ориентированный на облегчение редактирования текста в чудовищно ограниченном редакторе ed можно с тем же успехом применить в современном мире разноцветных полноэкранных редакторов, таких, как Emacs и Vim и распределённых систем контроля версий, совершенно немыслимых в 1970-х, очень многое говорит о мощи юниксового подхода.



Если вас интересует ранняя документация к UNIX — в том числе Второе Издание Руководства для Начинающих Кернигана — посмотрите на 7th Edition manuals благородно выложенное Bell Labs в сеть в виде PDF файлов а также в виде текстовых файлы, с разметкой для troff. Обратите внимание — из troff файлов и по сей день можно собрать готовый документ, который можно просматривать современными средствами — попробуйте-ка провернуть этот фокус с форматированным текстом из любых других редакторов 1970-х!



Послесловие от переводчика:



Почему я созрел опубликовать этот перевод только сейчас? Всё в общем просто. На Хабре недавно появилась поддержка формата Markdown, чему я был несказанно рад. Только вот выяснилось, что строки Хабр почему-то не склеивает, хотя Markdown не должен склеивать строки если только они кончаются двумя висячими пробелами.



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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307388/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
eugene20237

Linux: как посмотреть список открытых портов в системе?

Среда, 22 Июня 2016 г. 23:20 (ссылка)

lsof -Pni4

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Разработка Docker контейнеров с помощью системы многоцелевых сценариев Sparrow

Четверг, 02 Июня 2016 г. 14:28 (ссылка)

В этой статье я хотел бы рассказать как можно создавать сценарии сборки имиджей для Docker контейнеров с помощью системы многоцелевых сценариев Sparrow*.



Читать дальше →

https://habrahabr.ru/post/302278/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Linux Programming Interface

Пятница, 29 Апреля 2016 г. 16:28 (ссылка)

Здравствуйте, уважаемые читатели! С наступающими вас праздниками.



В последней апрельской публикации мы хотели бы рассказать вам о замечательной книге Майкла Керриска «Linux Programming Interface», которая в очередной раз вернулась в наше поле зрения благодаря превосходным продажам другой литературы по Linux:







Конечно, сложная книга о системном программировании объемом 1500+ страниц — литература, прямо скажем, на любителя. Но, поскольку отзывы о ней до сих пор восторженные, а нам потратиться на Linux завсегда не жалко предлагаем почитать ее обзор, опубликованный в далеком 2011 году.





Книга Майкла Керриска «The Linux Programming Interface» (TLPI) в первую очередь ориентирована на системных программистов, работающих с Linux, но целевая аудитория ими далеко не ограничивается. Хотя это и объемистый том (говорят, «таким можно быка пришибить»), читается книга на удивительно легко — и если вы ее просто пролистываете, и если штудируете каждый абзац. Здесь вы найдете энциклопедическую информацию об интерфейсе системных вызовов ядра Linux, но весь материал изложен в очень доступном стиле. В общем, это отличный справочник, который займет достойное место в библиотеке любого специалиста по Linux, работающего как с ядром, так и с пользовательским пространством, а также заинтересует некоторых из тех, кто не занимается Linux профессионально.



Керриск занимается поддержкой man-справки по Linux с 2004 года, поэтому отлично представляет себе Linux API. Как он упоминает в предисловии, возможно, вы уже знакомы с некоторыми его работами, а именно с разделами 2, 3, 4 и 5 этой справки. Но книга – не просто сборник статей из справки, хотя тематически во многом им близка. Ее материал организован иначе и изложен значительно более живым, популярным стилем.



Объем книги – около 1500 страниц, поэтому написать по ней обзор было не так просто. Однако, приступив к чтению, я вскоре ею увлекся. Керриск внятно описывает системные вызовы Linux и другие элементы API. Я решил прочитать лишь наиболее заинтересовавшие меня главы, а остальное пропустить, но в итоге прочитал гораздо больше, чем собирался.



Книга состоит из 64 глав, в каждой из которых примерно 20 страниц. Поэтому материал легко усваивается небольшими фрагментами, можно читать книгу и параллельно заниматься другими задачами. Основное внимание Керриск уделяет Linux, однако не забывает и о других разновидностях UNIX, отмечает, чем другие UNIX-подобные системы отличаются от Linux. Автор внимательно рассматривает различные стандарты, описывающие поведение Linux – в частности, POSIX и Single UNIX Specification (SUS) — указывая, где в Linux соблюдаются и где не соблюдаются эти стандарты.



Книга начинается с исторического экскурса: от таких классиков как Томпсон и Ричи до недавнего прошлого, с рассмотрением различных ветвей древа UNIX. Затем автор рассказывает, что такое операционная система, какую роль в ней играет ядро, а также излагает некоторые общие концепции, составляющие суть Unix (и Linux). Хотя для большинства корифеев Linux здесь нет никаких секретов, эта информация пригодится тем, кто раньше работал с другими операционными системами. Идеи «все — файл» и «файл — это просто поток байт» описаны настолько доступно, что любой системный программист, познакомившись с книгой, сможет быстро вступить на «путь Unix».



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



В каждой главе приводятся понятные образцы кода, которые удобно читать. Важно, что эти примеры очень помогают напрактиковаться в теме, а некоторые из листингов легко можно доделать до хороших утилит. Весь исходный код доступен на сайте man7.org/tlpi и является свободным, выпущен по лицензии Affero GPLv3. Кроме того, в каждой главе есть упражнения для читателя, решения некоторых из них даны в приложении.



Итак, о чем же книга? Легко сказать «обо всем сразу», но это будет своеобразная отговорка, причем неточная. В книге вы найдете множество глав о файлах, файловом вводе/выводе, расширенных атрибутах, списках контроля доступа (ACL). Есть глава о каталогах и ссылках, а в другой главе рассматривается вызов inotify, позволяющий получать уведомления о событиях, происходящих в файлах.



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



Пожалуй, в книге слишком много глав о межпроцессной коммуникации (IPC), по одной главе посвящено каждому IPC-механизму в составе System V (разделяемая память, очереди сообщений и семафоры). Также есть по главе о каждом из трех POSIX-вариантов этих типов IPC. Как по POSIX, так и по System V IPC есть своя вводная глава кроме тех глав, в которых излагаются подробности о каждом типе. Между двумя разделами о механизмах System V и POSIX IPC втиснуты две главы об отображении на память и об операциях с виртуальной памятью, которые, возможно, лучше было бы поставить в другой части книги. Еще есть глава, в которой делается введение в IPC и глава о более традиционных каналах Unix и очередях FIFO. Всего насчитывается двенадцать глав, связанных с IPC, после чего автор начинает рассматривать API сокетов.



После IPC идет глава о блокировке файлов, а затем шесть глав о сокетах. В этих главах рассматриваются сокеты Unix и сокеты Интернета, а также рассказывается о серверном дизайне и освещаются сложные темы, связанные с сокетами. Книга заканчивается главами о терминалах и псевдотерминалах, между которыми как-то затесалась глава «Альтернативные модели ввода/вывода». Это интересная глава, в которой рассматриваются вызовы select(), poll(), epoll(), сигнально-управляемый ввод/вывод и некоторые другие темы. Но расположена она все-таки немного странно.



Само собой, содержание книги этим не ограничивается. После ее прочтения особенно впечатляет, насколько велик API Linux/Unix. В книге также рассматриваются некоторые недостатки и морально устаревшие детали, сохранившиеся в API. Керриск ничуть не стесняется делать в нужных местах подобные замечания: «Вообще, очередями сообщений System V обычно лучше не пользоваться».



Есть две темы, о которых я очень хотел почитать, но которые плохо раскрыты в книге. Во-первых, это контейнеры и пространства имен, которые лишь вскользь упоминаются при обсуждении флагов системного вызова clone(). Более странным показалось, что в книге почти не упоминается системный вызов ptrace(). В тех немногих местах, где он все-таки фигурирует, читателей отсылают к man-справке ptrace(2).



Разумеется, кроме интерфейса системных вызовов можно было бы рассмотреть и другие элементы Linux API – навскидку вспоминаются sysf, splice() и perf – но Керриску явно приходилось выбирать, что включить в книгу, а от чего отказаться. В принципе, автор справился хорошо. Некоторые технические книги по Linux достаточно быстро устаревают, но в случае с этой работой проблема устаревания стоит не так остро как, например, с книгой об устройстве ядра.



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



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





Актуальность книги






































Проголосовало 42 человека. Воздержалось 28 человек.




Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.





Original source: habrahabr.ru.

https://habrahabr.ru/post/282776/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Linux Programming Interface

Пятница, 29 Апреля 2016 г. 16:28 (ссылка)

Здравствуйте, уважаемые читатели! С наступающими вас праздниками.



В последней апрельской публикации мы хотели бы рассказать вам о замечательной книге Майкла Керриска «Linux Programming Interface», которая в очередной раз вернулась в наше поле зрения благодаря превосходным продажам другой литературы по Linux:







Конечно, сложная книга о системном программировании объемом 1500+ страниц — литература, прямо скажем, на любителя. Но, поскольку отзывы о ней до сих пор восторженные, а нам потратиться на Linux завсегда не жалко предлагаем почитать ее обзор, опубликованный в далеком 2011 году.





Книга Майкла Керриска «The Linux Programming Interface» (TLPI) в первую очередь ориентирована на системных программистов, работающих с Linux, но целевая аудитория ими далеко не ограничивается. Хотя это и объемистый том (говорят, «таким можно быка пришибить»), читается книга на удивительно легко — и если вы ее просто пролистываете, и если штудируете каждый абзац. Здесь вы найдете энциклопедическую информацию об интерфейсе системных вызовов ядра Linux, но весь материал изложен в очень доступном стиле. В общем, это отличный справочник, который займет достойное место в библиотеке любого специалиста по Linux, работающего как с ядром, так и с пользовательским пространством, а также заинтересует некоторых из тех, кто не занимается Linux профессионально.



Керриск занимается поддержкой man-справки по Linux с 2004 года, поэтому отлично представляет себе Linux API. Как он упоминает в предисловии, возможно, вы уже знакомы с некоторыми его работами, а именно с разделами 2, 3, 4 и 5 этой справки. Но книга – не просто сборник статей из справки, хотя тематически во многом им близка. Ее материал организован иначе и изложен значительно более живым, популярным стилем.



Объем книги – около 1500 страниц, поэтому написать по ней обзор было не так просто. Однако, приступив к чтению, я вскоре ею увлекся. Керриск внятно описывает системные вызовы Linux и другие элементы API. Я решил прочитать лишь наиболее заинтересовавшие меня главы, а остальное пропустить, но в итоге прочитал гораздо больше, чем собирался.



Книга состоит из 64 глав, в каждой из которых примерно 20 страниц. Поэтому материал легко усваивается небольшими фрагментами, можно читать книгу и параллельно заниматься другими задачами. Основное внимание Керриск уделяет Linux, однако не забывает и о других разновидностях UNIX, отмечает, чем другие UNIX-подобные системы отличаются от Linux. Автор внимательно рассматривает различные стандарты, описывающие поведение Linux – в частности, POSIX и Single UNIX Specification (SUS) — указывая, где в Linux соблюдаются и где не соблюдаются эти стандарты.



Книга начинается с исторического экскурса: от таких классиков как Томпсон и Ричи до недавнего прошлого, с рассмотрением различных ветвей древа UNIX. Затем автор рассказывает, что такое операционная система, какую роль в ней играет ядро, а также излагает некоторые общие концепции, составляющие суть Unix (и Linux). Хотя для большинства корифеев Linux здесь нет никаких секретов, эта информация пригодится тем, кто раньше работал с другими операционными системами. Идеи «все — файл» и «файл — это просто поток байт» описаны настолько доступно, что любой системный программист, познакомившись с книгой, сможет быстро вступить на «путь Unix».



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



В каждой главе приводятся понятные образцы кода, которые удобно читать. Важно, что эти примеры очень помогают напрактиковаться в теме, а некоторые из листингов легко можно доделать до хороших утилит. Весь исходный код доступен на сайте man7.org/tlpi и является свободным, выпущен по лицензии Affero GPLv3. Кроме того, в каждой главе есть упражнения для читателя, решения некоторых из них даны в приложении.



Итак, о чем же книга? Легко сказать «обо всем сразу», но это будет своеобразная отговорка, причем неточная. В книге вы найдете множество глав о файлах, файловом вводе/выводе, расширенных атрибутах, списках контроля доступа (ACL). Есть глава о каталогах и ссылках, а в другой главе рассматривается вызов inotify, позволяющий получать уведомления о событиях, происходящих в файлах.



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



Пожалуй, в книге слишком много глав о межпроцессной коммуникации (IPC), по одной главе посвящено каждому IPC-механизму в составе System V (разделяемая память, очереди сообщений и семафоры). Также есть по главе о каждом из трех POSIX-вариантов этих типов IPC. Как по POSIX, так и по System V IPC есть своя вводная глава кроме тех глав, в которых излагаются подробности о каждом типе. Между двумя разделами о механизмах System V и POSIX IPC втиснуты две главы об отображении на память и об операциях с виртуальной памятью, которые, возможно, лучше было бы поставить в другой части книги. Еще есть глава, в которой делается введение в IPC и глава о более традиционных каналах Unix и очередях FIFO. Всего насчитывается двенадцать глав, связанных с IPC, после чего автор начинает рассматривать API сокетов.



После IPC идет глава о блокировке файлов, а затем шесть глав о сокетах. В этих главах рассматриваются сокеты Unix и сокеты Интернета, а также рассказывается о серверном дизайне и освещаются сложные темы, связанные с сокетами. Книга заканчивается главами о терминалах и псевдотерминалах, между которыми как-то затесалась глава «Альтернативные модели ввода/вывода». Это интересная глава, в которой рассматриваются вызовы select(), poll(), epoll(), сигнально-управляемый ввод/вывод и некоторые другие темы. Но расположена она все-таки немного странно.



Само собой, содержание книги этим не ограничивается. После ее прочтения особенно впечатляет, насколько велик API Linux/Unix. В книге также рассматриваются некоторые недостатки и морально устаревшие детали, сохранившиеся в API. Керриск ничуть не стесняется делать в нужных местах подобные замечания: «Вообще, очередями сообщений System V обычно лучше не пользоваться».



Есть две темы, о которых я очень хотел почитать, но которые плохо раскрыты в книге. Во-первых, это контейнеры и пространства имен, которые лишь вскользь упоминаются при обсуждении флагов системного вызова clone(). Более странным показалось, что в книге почти не упоминается системный вызов ptrace(). В тех немногих местах, где он все-таки фигурирует, читателей отсылают к man-справке ptrace(2).



Разумеется, кроме интерфейса системных вызовов можно было бы рассмотреть и другие элементы Linux API – навскидку вспоминаются sysf, splice() и perf – но Керриску явно приходилось выбирать, что включить в книгу, а от чего отказаться. В принципе, автор справился хорошо. Некоторые технические книги по Linux достаточно быстро устаревают, но в случае с этой работой проблема устаревания стоит не так остро как, например, с книгой об устройстве ядра.



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



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





Актуальность книги






































Проголосовало 2 человека. Воздержалось 4 человека.




Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282776/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
zerg_from_hive

осиновый кол

Вторник, 01 Марта 2016 г. 12:02 (ссылка)

Новость, однако: "Компании SCO и IBM согласились принять решение суда и прекратить судебную тяжбу по претензиям SCO к IBM. 2 февраля окружной суд штата Юта принял решение об отклонении последних оставшихся претензий SCO к IBM и дал время до 26 февраля решить, согласны ли они с решением или намерены продолжить судебный процесс.

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


Кажется, ночь живых мертвецов (сериал "SCO contra mundi" начался в 2003 году) наконец-то закончилась осиновым колом. Правда, один из комментаторов новости несколько более оптимистичен касательно покойника: "SCO хоронили -- три баяна порвали. И ещё десяток порвут. The show must go on!" 8-)

Метки:   Комментарии (2)КомментироватьВ цитатник или сообщество
zerg_from_hive

vim cheat sheet

Пятница, 18 Декабря 2015 г. 17:04 (ссылка)

Собственно, краткий справочник по командным клавишам vi/vim, позаимствованный тут. Мало ли, вдруг кому-то понадобится, к тому же там достаточно понятно, почему те или иные действия завязаны на ту или иную клавишу.
VIM-TIPS (700x494, 122Kb)

Метки:   Комментарии (1)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Мифы о /dev/urandom

Среда, 16 Декабря 2015 г. 13:04 (ссылка)


image



Наверняка многие из вас неоднократно сталкивались с мифами о /dev/urandom и /dev/random. Может быть, в некоторые из них вы даже верите. В этом посте мы сорвём покровы со всех этих мифов и разберём настоящие сильные и слабые стороны этих генераторов случайных чисел.

Читать дальше →

http://habrahabr.ru/post/273147/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
zerg_from_hive

UNIX-коаны

Вторник, 15 Декабря 2015 г. 21:53 (ссылка)

Практически полный набор переведённых на русский UNIX-коанов обнаружился на хабре. Весьма рекомендую прочитать и проникнуться духом UNIX. 8-)

Мастер Фу и 10 000 строк
Метки:   Комментарии (2)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Разноцветные терминалы

Понедельник, 02 Ноября 2015 г. 12:49 (ссылка)





В этой публикации я расскажу о некоторых трюках, которые украсят будни любого системного администратора Linux (и не только). Все они связаны с переменной PS1 оболочки bash. Переменная PS1 определяет, как будет выглядеть приглашение для ввода новых команд. И каждый пользователь может переопределять её как пожелает, например, в файле ~/.bashrc (который выполняется при запуске bash и используется для в том числе для конфигурации).



Для начала рассмотрим простой вариант, мой любимый формат командной строки.



PS1='\t j\j \u@\h:\w\n\$ '


Результат будет вот такой:



17:42:46 j0 olleg@petrel:~
$


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




  • \t — вывод «текущего времени», на самом деле это получается время завершения выполнения предыдущей команды, удобно когда перед глазами.

  • j\j — выводит символ j и после него количество запущенных job, т.е. процессов в фоне. Это тоже удобно иметь перед глазами чтобы случаем про них не забыть когда соберешься закрыть терминал.

  • \u@\h — имя пользователя и название сервера. Если работаете с несколькими серверами через удаленные терминалы — чтобы не путаться.

  • \w — после двоеточия — рабочая директория.

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

  • \$ — на новой строке будет выводится символ либо $ для обычного пользователя либо # для root'а и отделив его пробелом можно приглашать вводить новую команду.



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



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




# .bash_local
# change cursor and prompt color
cursor_color='#0087FF'
prompt_color='33'


Просто заношу коды цвета в переменные. Но, как вы заметили, что способ задания цвета для курсора и для текста командной строки — разный. Почему-то так исторический получилось. Чтобы понять, какой цвет каким кодом кодируется, есть подходящая картинка.



image



Посредине — обозначение цвета для цвета курсора, снизу — обозначение цвета для текста. Как вы можете увидеть, что я для текста и курсора использую цвет морской волны. Т.к. название сервера petrel («буревестник»), то он ассоциируется у меня с этим цветом.



Теперь .bashrc, тоже показываю его не полностью, а только то что имеет отношение к теме:




# .bashrc
# local stuff
[[ -f ~/.bash_local ]] && . ~/.bash_local


Тут я вставляю код из .bash_local в общий файл. Таким образом определяться ранее описанные переменные с цветом сервера.




# set to red
root_cursor_color='#FF0000'
root_prompt_color='196'


Еще две переменные определяю с чисто красным цветом, он будет использоваться для маркировки терминалов привелигированного пользователя (root'а).




#my favorite PS1
case "$TERM" in
xterm*|rxvt*)
PS1='\[\e[38;5;'$prompt_color'm\]\t j\j \u@\h:\w\n'
[[ $UID == 0 ]] && { prompt_color=$root_prompt_color;cursor_color=$root_cursor_color; }
PS1="$PS1"'\[\e[m\e]12;'$cursor_color'\a\e[38;5;'$prompt_color'm\]\$ \[\e[m\]'
;;
*)
PS1='\t j\j \u@\h:\w\n\$ '
;;
esac


Тут проверяется какой используется терминал. Для любого неизвестного или неподдерживающего цвета будет использоваться приглашение без цвета (PS1='\t j\j \u@\h:\w\n\$ ') так, как я это описал в начале статьи. Но если имя терминала начинается на xterm или rxvt, например, так себя позиционирует терминал Gnome, начинаем кудесить с цветом. Первая строчка — задаем цвет текста — цвет сервера и выводим первую строку приглашения ввода команд. Она всегда будет окрашена в цвет сервера. Вторая строчка — проверяем, работаем ли мы под непривелигированным или привелигированным пользователем (root'ом). Если root — то переопределяем цвета на красный. Третья строчка — формируем вторую строчку приглашения и определяем цвет курсора в терминале. Т.е. там у нас получится либо $ и через пробел курсор, оба покрашенные в цвет сервера, если пользователь обычный. Либо красный # и через пробел красный курсор, если это root.




# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac


А это, если честно, один в один скопированно из первоначального .bashrc от Дебиана. Знаю, что этот код видоизменяет title bar у окна, размещает там информацию об пользователе, сервере и домашней директории. Но поскольку этот код придумал не я, комментировать его не буду.



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

Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/269967/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<unix - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda