Использование комманд diff и patch

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

В этой статье используются без объяснения некоторые базовые команды Linux, такие как смена смена директории, копирование файлов и редактирование текстовых файлов.

Использование diff для создания простого патча

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

[rechosen@localhost ~]$ diff originalfile updatedfile

Конечно, надо заменить originalfile и updatedfile соответствующими именами файлов. В результате должно получиться что-то вроде этого:

1c1
 
< These are a few words.
 
\ No newline at end of file
 
---
 
> These still are just a few words.
 
\ No newline at end of file

Обратите внимание: Что бы продемонстрировать создание простого патча, я использовал оригинальный файл, содержащий строку «These are a few words.», и измененный файл, содержащий строку «These still are just a few words.» Вы можете создать эти файлы сами, если хотите запустить команду из статьи и получить тот же результат.

1c1 показывает номер строки и то, что с ней надо сделать. Обратите внимание, что может быть сразу несколько строк(например, 12,15, что означает со строки 12 до строки 15). Символ «c» означает, что патч заменит эту строку. Есть еще два других символа: «a» и «d». Они означают «добавить»(add) и «удалить»(delete) соответственно. Таким образом, синтаксис следующий: (номер строки или диапазон строк)(c,a или d)(номер строки или диапазон строк), хотя когда используются «a» или «d», одна из частей (номер строки или диапазон строк) может содержать только номер одной строки.

  • Когда используется «c», номера строк слева — это строки в оригинальном файле, которые надо заменить строками, находящимися в патче, а номера строк справа — это строки, которые должны быть в пропатченном файле.
  • Когда используется «a», номер слева может быть только номером одной строки, который показывает, где надо добавить строку в пропатченном файле, а номера строк справа — это строки, которые должны быть в пропатченном файле.
  • Когда используется «d», номера строк слева — это строки, которые надо удалить, чтобы получить пропатченную версию файла, а номер строки справа может быть только номером одной строки, который показывает где будут строки в пропатченном файле, если они не будут удалены. Вы можете подумать, что последний номер не нужен, но не забывайте, что патч можно применить для восстаноления исходного файла. Это будет объяснено позже.

Знак «<» означает, что патч должен удалить символы после этого знака, а знак «>» означает, что символы после этого знака надо добавить. Когда надо заменить строки («c» между номерами строк), вы увидите оба знака: и «<«, и «>». Когда надо добавить строку («a» между номерами строк), вы увидите только знак «>», а когда надо удалить строку («d» между номерами строк), вы увидите только знак «<«.

Строка «\ No newline at end of file» появилась из-за того, что я не не нажал enter после того как набрал слова. Считается хорошим тоном заканчивать текстовый файл пустой строкой. Некоторым программам она необходима для работы. Поэтому эта строка появилась после работы команды diff. Добавим пустые строки в конец файлов, и получим более короткий вывод команды diff:

1c1
 
< These are a few words.
 
---
 
> These still are just a few words.

Как вы возможно заметили, я не объяснил что означают 3 знака «-«. Они означают конец строк, которые надо заменить и начало строк на которые надо заменить. Разделение старых и новых строк. Вы увидите это знак только при замене («c» между номерами строк).

Если мы хотим создать патч, мы должны поместить вывод команды diff в файл. Конечно это можно сделать, скопировав его из консоли и вставив в вашем любимом текстовом редакторе, а затем сохранив этот файл, но есть способ проще. Мы можем с помощью bash направить вывод команды diff в текстовый файл:

[rechosen@localhost ~]$ diff originalfile updatedfile > patchfile.patch

Опять же не забудьте заменить originalfile и updatedfile на соответствующие имена файлов. Вы наверное знаете, что опция bash «>» работает со всеми командами. Это очень полезное свойство.

Применение простого патча, который мы создали

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

[rechosen@localhost ~]$ patch originalfile -i patchfile.patch -o updatedfile

Естественно, и здесь надо изменить имена файлов на необходимые. Если все прошло хорошо, должен получиться файл, идентичный обновленному. Вы можете убедиться в этом, используя команду diff с опцией «-s»:

[rechosen@localhost ~]$ diff -s updatedfile [/path/to/the/original/updatedfile]/updatefile

Замените текст между [ и ] на путь к оригинальному файлу. Например, если обновленный файл, который вы использовали при создании патча находится в родительской директории вышай текущей, то «[/path/to/the/original/updatedfile]» надо заменить на «..» (bash понимает это как родительскую директорию от текущей). И конечно надо изменить имена файлов на верные.

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

Контекстный патч

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

[rechosen@localhost ~]$ diff -c originalfile updatedfile

Результат получится следующий:

*** originalfile        2007-02-03 22:15:48.000000000 0100
 
--- updatedfile 2007-02-03 22:15:56.000000000 0100
 
***************
 
*** 1 ****
 
! These are a few words.
 
--- 1 ----
 
! These still are just a few words.

Как вы видите, здесь включено имя файла. Это значит, что нам не придется набирать его во время применения патча. Далее идет дата и время последнего изменения файла. строка с 15 «*» показывает начало изменений. Они показывают, что надо сделать со следующим блоком текста. Два номера 1 — это номера строк (здесь тоже может быть сразу несколько строк), а «!» означает, что строки надо заменить. Строка с «!» перед тремя «-» должна быть заменена второй строкой с «!», которая идет после трех «-«(конечно сам ! не будет включен; это синтаксис контекстного формата). Как вы можете видеть, здесь нет знаков «c», «a» и «d».Действие, которое нужно сделать, определяется символом в начале строки. «!» означает замену. Другие символы — «+», «-» и » » (пробел). «+» означает добавление, «-» означает удаление, а » » означает ничего не делать: патч использует его чтобы убедиться, что он изменяет правильную часть файла.

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

[rechosen@localhost ~]$ patch -i patchfile.patch -o updatedfile

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

Получение различий между несколькими файлами

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

[rechosen@localhost ~]$ diff originaldirectory/ updateddirectory/

Обратите внимание: Если в директория есть поддиректории, то надо использовать опцию «-r».

В результате должно получится что-то вроде этого:

diff originaldirectory/file1 updateddirectory/file1
 
1c1
 
< This is the first original file.
 
---
 
> This is the first updated file.
 
diff originaldirectory/file2 updateddirectory/file2
 
1c1
 
< This is the second original file.
 
---
 
> This is the second updated file.
 
14d13
 
< We're going to add something in this file and to delete this line.
 
26a26
 
> This is line has been added to this updated file.

Обратите внимание: Я создал несколько несколько файлов для примера. Вы можете скачать архив, содержащий эти файлы: http://www.linuxtutorialblog.com/resource/uploads/diffpatchexamplefiles.tar.gz.

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

Теперь используем контекстный формат:

diff -c originaldirectory/file1 updateddirectory/file1
 
*** originaldirectory/file1     2007-02-04 16:17:57.000000000 +0100
 
--- updateddirectory/file1      2007-02-04 16:18:33.000000000 +0100
 
***************
 
*** 1 ****
 
! This is the first original file.
 
--- 1 ----
 
! This is the first updated file.
 
diff -c originaldirectory/file2 updateddirectory/file2
 
*** originaldirectory/file2     2007-02-04 16:19:37.000000000 +0100
 
--- updateddirectory/file2      2007-02-04 16:20:08.000000000 +0100
 
***************
 
*** 1,4 ****
 
! This is the second original file.
 
  S
 
  O
 
--- 1,4 ----
 
! This is the second updated file.
 
  S
 
  O
 
***************
 
*** 11,17 ****
 
  C
 
  E
 
- We're going to add something in this file and to delete this line.
 
  S
 
  O
 
--- 11,16 ----
 
***************
 
*** 24,28 ****
 
--- 23,28 ----
 
  C
 
  E
 
+ This is line has been added to this updated file.
 
  Something will be added above this line.

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

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

Создать патч было легко, но использование директорий ставит следующую проблему: бедут ли патч изменять только соответствующие файлы в текущей директории, или будет использовать соответствующий путь, указанный в файле? Чтобы узнать это, смотрите следующую главу!

Применение патча к нескольким файлам

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

[rechosen@localhost ~]$ diff -c originaldirectory/ updateddirectory/ > patchfile.patch

Обратите внимание: мы используем контекстный формат патча, так как это является хорошим тоном.

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

[rechosen@localhost ~]$ patch -i patchfile.patch

Однако возникает ошибка, что невозможно найти файлы для патча. Команда пытается найти файл file1 в текущей директории (по умолчанию патч убирает все пути перед именем файла). И конено файла нет, так как мы пытаемся обновить файлы в директории originaldirectory. Поэтому мы должны заставить патч использовать полный путь. Это делается следующим образом:

[rechosen@localhost ~]$ patch -p0 -i patchfile.patch

Обратите внимание: Вы может подумать, что можно просто переместиться в originaldirectory и запустить патч. Но это не так! Так делать не стоит: если в в патче содержатся поддиректории, то он будет искать их в рабочей директории, и не найдет, или найдет не те. Используйте опцию «-p», чтобы заставить патч искать файлы в поддиректориях.

Опция «-p» говорит патчу сколько слэшей (включая то, что перед ними, обычно директории) нужно вырезать перед именем файла (обратите внимание, что при использовании опции «-p0», патч будет будет искать файлы и в originaldirectory и в updateddirectory).Когда мы устанавливаем 0, это означает что не надо удалять пути, но можно поставить 1, чтобы удалить первый слэш, или 2, чтобы удалить два слэша, и т.д. Это может быть полезно, если если в патче используется структура каталогов, отличная от вашей. Например, если в патче используется следующая структура каталогов:

(...)
 
*** /home/username/sources/program/originaldirectory/file1     2007-02-04 16:17:57.000000000 +0100
 
--- /home/username/sources/program/updateddirectory/file1      2007-02-04 16:18:33.000000000 +0100
 
(...)

Вам надо просто посчитать количество слэшей (/ (1) home/ (2) username/ (3) sources/ (4) program/ (5)) и передать это число в опцие «-p». Если вы используете «-p5», то патч будет искать и в originaldirectory/file1 и в updateddirectory/file1. Не забудьте, что патч рассматривает два слэша друг за другом (как в /home/username//sources) как один. Это вызвано тем, что иногда патч скрипты добавляют дополнительный слэш между директориями.

Восстановление оригинального файла из пропатченного

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

[rechosen@localhost ~]$ patch -p0 -R -i patchfile.patch

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

Унифицированный формат

Есть еще один формат вывода различий командой diff: унифицированный формат. Он более компактен, так как содержит уменьшенные контекстные строки. Однако он поддерживается только GNU diff и patch. Если вы его используете, вы должны быть уверены, что у пользователей, для которых патч предназначен, GNU patch. Linux допускает использование этого формата.

Унифицированный формат похож на контекстный, но это не одно и тоже. Патч в унифицированном формате можно создать так:

[rechosen@localhost ~]$ diff -u originaldirectory/ updateddirectory/

Результат будет седующий:

diff -u originaldirectory/file1 updateddirectory/file1
 
--- originaldirectory/file1     2007-02-04 16:17:57.000000000 +0100
 
+++ updateddirectory/file1      2007-02-04 16:18:33.000000000 +0100
 
@@ -1 +1 @@
 
-This is the first original file.
 
+This is the first updated file.
 
diff -u originaldirectory/file2 updateddirectory/file2
 
--- originaldirectory/file2     2007-02-04 16:19:37.000000000 +0100
 
+++ updateddirectory/file2      2007-02-04 16:20:08.000000000 +0100
 
@@ -1,4 +1,4 @@
 
-This is the second original file.
 
+This is the second updated file.
 
 S
 
 O
 
@@ -11,7 +11,6 @@
 
 C
 
 E
 
-We're going to add something in this file and to delete this line.
 
 S
 
 O
 
@@ -24,5 +23,6 @@
 
 C
 
 E
 
+This is line has been added to this updated file.
 
 Something will be added above this line.

Как вы видите, номера строк заключены между «@». Кроме того, есть дополнительный пробел после «+» или «-«. Это экономит несколько байт. Другое различие: в унифицированном формате нет специального знака для замены. Он просто удаляет старые строки («-«) и добавляет новые («+»). Разница между этими действиями заключается в том, что при замене используется один и тот же номер строки, а при удалении и добавлении разные.

Сравнение форматов

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

  • Нормальный формат наиболее совместимый. Любые команды похожие на diff/patch должны понять его. Его недостаток — это отсутствие контекста.
  • Контекстный формат широко распространен, но не все команды его понимают. Его преимущество в наличии контекста.
  • Унифицированный формат тоже включает контекст, и при этом более компактем. Но его поддерживает только GNU diff and patch.

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

Изменение количества контекстных строк

Можно заставить команду diff включать в патч сеньшее количество строк контекста, чем должно быть. В больших патчах это может сильон уменьшить его размер. Однако если уменьшить количество контекстных строк, это может привести в неработоспособности патча. Цитати из справки GNU diff: «Для большинства операций в патче должно быть хотя бы две строки контекста.»

Указать количество контестных строк можно несколькими способами:

  • Если вы хотит использовать контекстный формат, вы можете вы можете совместить эти указания, добавив в опцию «-C». Пример:
    [rechosen@localhost ~]$ diff -C 2 originaldirectory/ updateddirectory/

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

  • Если вы хотит использовать контекстный формат, вы можете вы можете совместить эти указания, добавив в опцию «-U». Пример:

    [rechosen@localhost ~]$ diff -U 2 originaldirectory/ updateddirectory/

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

  • Если не указывать какой формат вы хотите использовать, то команда будет выглядеть примерно так:
    [rechosen@localhost ~]$ diff -2 originaldirectory/ updateddirectory/

    Однако это будет работать только если вы определите формат. Вам необходимо использовать эту опцию или с «-c» или с «u».

Заключительные слова

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

Windows CMD: Поиск хостов в локальной сети

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

FOR /L %i IN (1,1,254) DO ping -n 1 \\192.168.0.%i | FIND /i "Reply">>c:\find_local_ip.txt

здесь каждый айпишник для адресов 192.168.0.1-254 пингуется один раз, после чего результат передается команде find, которая при отклике записывает результат в файл find_local_ip.txt

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

FOR /L %i in (1,1,254) DO shutdown \\192.168.0.%i

также с выходом всех пользователей (XP):

FOR /L %i in (1,1,254) DO shutdown \\192.168.0.%i /l

тоже самое для 2003 сервера:

FOR /L %i in (1,1,254) DO shutdown /r /m \\192.168.0.%i /d p:2:18

примечание: данная фича может быть запрещена локальной политикой безопасности в разделе прав пользователей, в XP shutdown встроенная команда, если ее нет, то нужно будет скачать.

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

посмотреть использующиеся порты —

netstat -an |find /i "listening"

посмотреть порты с установленными соединениями:

netstat -an |find /i "established"

с идентификаторами процессов:

netstat -ao |find /i "listening"

помнится в бесплатном пакете W2K Resource Kit была хорошая утилитка, PULIST, позволяющая посмотреть процесс, использующий порт и использующую его программу, например есть установленное соединение по 80 порту и ни один броузер не запущен, как найти программу, которая использует данный порт —

netstat -no

выдаст, что есть процесс номер 1234, использующий 80 порт,

pulist |find /i "1234"

и покажет, что это идет обновление антивируса.

Частые ошибки программирования на Bash

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

Большинство имеющихся руководств посвящено тому, как надо писать. Я же расскажу о том, как писать НЕ надо 🙂

Данный текст является вольным переводом вики-страницы “Bash pitfalls” по состоянию на 13 декабря 2008 года. В силу викиобразности исходника, этот перевод может отличаться от оригинала. Поскольку объем текста слишком велик для публикации целиком, он будет публиковаться частями, по мере перевода.

1. for i in `ls *.mp3`

Одна из наиболее часто встречающихся ошибок в bash-сериптах — это циклы типа такого:

for i in `ls *.mp3`; do     # Неверно!
some command $i         # Неверно!
done

Это не сработает, если в названии одного из файлов присутствуют пробелы, т.к. результат подстановки команды ls *.mp3 подвергается разбиению на слова. Предположим, что у нас в текущей директории есть файл 01 — Don’t Eat the Yellow Snow.mp3. Цикл for пройдётся по каждому слову из названия файла и $i примет значения: «01», «-«, «Don’t», «Eat», «the», «Yellow», «Snow.mp3».

Заключить всю команду в кавычки тоже не получится:

for i in "`ls *.mp3`"; do   # Неверно!
...

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

На самом деле использование ls совершенно излишне: это внешняя команда, которая просто не нужна в данном случае. Как же тогда правильно? А вот так:

for i in *.mp3; do         # Гораздо лучше, но...
some command "$i"      # ... см. подвох №2
done

Предоставьте bash’у самому подставлять имена файлов. Такая подстановка не будет приводить к разделению строки на слова. Каждое имя файла, удовлетворяющее шаблону *.mp3, будет рассматриваться как одно слово, и цикл пройдёт по каждому имени файла по одному разу.

Дополнительные сведения можно найти в п. 20 Bash FAQ.

Внимательный читатель должен был заметить кавычки во второй строке вышеприведённого примера. Это плавно подводит нас к подвоху №2.

2. cp $file $target

Что не так в этой команде? Вроде бы ничего особенного, если вы абсолютно точно знаете, что в дальнейшем переменные $file и $target не будут содержать пробелов или подстановочных символов.

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

cp "$file" "$target"

Без двойных кавычек скрипт выполнит команду cp 01 — Don’t Eat the Yellow Snow.mp3 /mnt/usb, и вы получите массу ошибок типа cp: cannot stat `01′: No such file or directory. Если в значениях переменных $file или $target содержатся символы *, ?, [..] или (..), используемые в шаблонах подстановки имен файлов (”wildmats”), то в случае существования файлов, удовлетворяющих шаблону, значения переменных будут преобразованы в имена этих файлов. Двойные кавычки решают эту проблему, если только «$file» не начинается с дефиса -, в этом случае cp думает, что вы пытаетесь указать ему еще одну опцию командной строки.

Один из способов обхода — вставить двойной дефис (—) между командой cp и её аргументами. Двойной дефис сообщит cp, что нужно прекратить поиск опций:

cp -- "$file" "$target"

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

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

for i in ./*.mp3; do
cp "$i" /target
...

Даже если у нас есть файл, название которого начинается с “-”, механизм подстановки шаблонов гарантирует, что переменная содержит нечто вроде ./-foo.mp3, что абсолютно безопасно для использования вместе с cp.

3. [ $foo = «bar» ]

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

Этот код ошибочен по двум причинам:

1. Если переменная, используемая в условии [, не существует или пуста, строка

[ $foo = "bar" ]

будет воспринята как

[ = "bar" ]

что вызовет ошибку “unary operator expected”. (Оператор “=” бинарный, а не унарный, поэтому команда [ будет в шоке от такого синтаксиса)
2. Если переменная содержит пробел внутри себя, она будет разбита на разные слова перед тем, как будет обработана командой [:

[ multiple words here = "bar" ]

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

Правильно будет так:

[ "$foo" = bar ]       # уже близко!

Но этот вариант не будет работать, если $foo начинается с -.

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

[[ $foo = bar ]]       # правильно!

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

Возможно, вы видели код типа такого:

[ x"$foo" = xbar ]    # тоже правильно!

Хак x»$foo» требуется в коде, который должен работать в древних шеллах, не поддерживающих [[, потому что если $foo начинается с -, команда [ будет дезориентирована.

Если одна из частей выражения — константа, можно сделать так:

[ bar = "$foo" ]      # так тоже правильно!

Команду [ не волнует, что выражение справа от знака “=” начинается с -. Она просто использует это выражение, как строку. Только левая часть требует такого пристального внимания.

4. cd `dirname “$f”`

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

cd "`dirname "$f"`"

Что здесь не совсем очевидно, это последовательность кавычек. Программист на C мог бы предположить, что сгруппированы первая и вторая кавычки, а также третья и четвёртая. Однако в данном случае это не так. Bash рассматривает двойные кавычки внутри команды как первую пару, и наружные кавычки — как вторую.

Другими словами, парсер рассматривает обратные кавычки (`) как уровень вложенности, и кавычки внутри него отделены от внешних.

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

cd "$(dirname "$f")"

Кавычки внутри $() сгруппированы.

5. [ «$foo» = bar && «$bar» = foo ]

Нельзя использовать && внутри «старой» команды test или её эквивалента [. Парсер bash’а видит && снаружи [[ ]] или (( )) и разбивает вашу команду на две, перед и после &&. Лучше используйте один из вариантов:

[ bar = "$foo" -a foo = "$bar" ]       # Правильно!
[ bar = "$foo" ] && [ foo = "$bar" ]   # Тоже правильно!
[[ $foo = bar && $bar = foo ]]         # Тоже правильно!

Обратите внимание, что мы поменяли местами константу и переменную внутри [ — по причинам, рассмотренным в предыдущем пункте.

То же самое относится и к ||. Используйте [[, или -o, или две команды [.

6. [[ $foo > 7 ]]

Если оператор > используется внутри [[ ]], он рассматривается как оператор сравнения строк, а не чисел. В некоторых случаях это может сработать, а может и не сработать (и это произойдёт как раз тогда, когда вы меньше всего будете этого ожидать). Если > находится внутри [ ], всё ещё хуже: в данном случае это перенаправление вывода из файлового дескриптора с указанным номером. В текущем каталоге появится пустой файл с названием 7, и команда test завершится с успехом, если только переменная $foo не пуста.

Поэтому операторы > и < для сравнения чисел внутри [ .. ] или [[ .. ]] использовать нельзя.

Если вы хотите сравнить два числа, используйте (( )):

((foo > 7))                             # Правильно!

Если вы пишете для Bourne Shell (sh), а не для bash, правильным способом является такой:

[ $foo -gt 7 ]                          # Тоже правильно!

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

Двойные квадратные скобки также поддерживают такой синтаксис:

[[ $foo -gt 7 ]]                        # Тоже правильно!

7. count=0; grep foo bar | while read line; do ((count++)); done; echo “number of lines: $count”

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

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

В данном случае цикл for является частью конвейера и выполняется в отдельной подоболочке со своей копией переменной $count, инизиализированной значением переменной $count из родительской оболочки: “0?. Когда цикл заканчивается, использованная в цикле копия $count отбрасывается и команда echo показывает неизменённое начальное значение $count (”0?).

Обойти это можно несколькими способами.

Можно выполнить цикл в своей подоболочке (слегка кривовато, но так проще и понятней и работает в sh):

# POSIX compatible
count=0
cat /etc/passwd | (
while read line ; do
count=$((count+1))
done
echo "total number of lines: $count"
)

Чтобы полностью избежать создания подоболочки, используйте перенаправление (в Bourne shell (sh) для перенаправления также создаётся subshell, поэтому будьте внимательны, такой трюк сработает только в bash):

# только для bash!
count=0
while read line ; do
count=$(($count+1))
done < /etc/passwd
echo "total number of lines: $count"

Предыдущий способ работает только для файлов, но что делать, если нужно построчно обработать вывод команды? Используйте подстановку процессов:

while read LINE; do
echo "-> $LINE"
done < <(grep PATH /etc/profile)

Ещё пара интересных способов разрешения проблемы с субшеллами обсуждается в Bash FAQ #24.

8. if [grep foo myfile]

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

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

Синтаксис if:

if COMMANDS
then
COMMANDS
elif COMMANDS     # необязательно
then
COMMANDS
else              # необязательно
COMMANDS
fi

Как видите, в синтаксисе if нет никаких [ или [[!

Ещё раз, [ — это команда, которая принимает аргументы и выдаёт код возврата; как и все нормальные команды, она может выводить сообщения об ошибках, но, как правило, ничего не выдаёт в STDOUT.

if выполняет первый набор команд, и в зависимости от кода возврата последней команды из этого набора определяет, будет ли выполнен блок команд из секции «then» или же выполнение скрипта продолжится дальше.

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

if grep foo myfile > /dev/null; then
...
fi

Обратите внимание, что мы отбрасываем стандартный вывод grep: нам не нужен результат поиска, мы просто хотим знать, присутствует ли строка в файле. Если grep находит строку, он возвращает 0, и условие выполняется; в противном случае (строка в файле отсутствует) grep возвращает значение, отличное от 0. В GNU grep перенаправление >/dev/null можно заменить опцией -q, которая говорит grep’у, что ничего выводить не нужно.

9. if [bar=»$foo»]

Как было объяснено в предыдущем параграфе, [ — это команда. Как и в случае любой другой команды, bash предполагает, что после команды следует пробел, затем первый аргумент, затем снова пробел, и т.д. Поэтому нельзя писать всё подряд без пробелов! Правильно вот так:

if [ bar = "$foo" ]

bar, =, «$foo» (после подстановки, но без разделения на слова) и ] являются аргументами команды [, поэтому между каждой парой аргументов обязательно должен присутствовать пробел, чтобы шелл мог определить, где какой аргумент начинается и заканчивается.

10. if [ [ a = b ] && [ c = d ] ]

Снова та же ошибка. [ — команда, а не синтаксический элемент между if и условием, и тем более не средство группировки. Вы не можете взять синтаксис C и переделать его в синтаксис bash простой заменой круглых скобок на квадратные.

Если вы хотите реализовать сложное условие, вот правильный способ:

if [ a = b ] && [ c = d ]

Заметьте, что здесь у нас две команды после if, объединённые оператором &&. Этот код эквивалентент такой команде:

if test a = b && test c = d

Если первая команда test возвращает значение false (любое ненулевое число), тело условия пропускается. Если она возвращает true, выполняется второе условие; если и оно возвращает true, то выполняется тело условия.

11. cat file | sed s/foo/bar/ > file

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

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

sed 's/foo/bar/g' file > tmpfile && mv tmpfile file

Следующий фрагмент будет работать только при использовании GNU sed 4.x и выше:

sed -i 's/foo/bar/g' file

Обратите внимание, что при этом тоже создаётся временный файл и затем происходит переименование — просто это делается незаметно.

В *BSD-версии sed необходимо обязательно указывать расширение, добавляемое к запасной копии файла. Если вы уверены в своем скрипте, можно указать нулевое расширение:

sed -i '' 's/foo/bar/g' file

Также можно воспользоваться perl 5.x, который, возможно, встречается чаще, чем sed 4.x:

perl -pi -e 's/foo/bar/g' file

Различные аспекты задачи массовой замены строк в куче файлов обсуждаются в Bash FAQ #21.

12. echo $foo

Эта относительно невинно выглядящая команда может привести к неприятным последствиям. Поскольку переменная $foo не заключена в кавычки, она будет не только разделена на слова, но и возможно содержащийся в ней шаблон будет преобразован в имена совпадающих с ним файлов. Из-за этого bash-программисты иногда ошибочно думают, что их переменные содержат неверные значения, тогда как с переменными всё в порядке — это команда echo отображает их согласно логике bash, что приводит к недоразумениям.

MSG="Please enter a file name of the form *.zip"
echo $MSG

Это сообщение разбивается на слова и все шаблоны, такие, как *.zip, раскрываются. Что подумают пользователи вашего скрипта, когда увидят фразу:

Please enter a file name of the form freenfss.zip lw35nfss.zip

Вот ещё пример:

VAR=*.zip       # VAR содержит звёздочку, точку и слово "zip"
echo "$VAR"     # выведет *.zip
echo $VAR       # выведет список файлов, чьи имена заканчиваются на .zip

На самом деле, команда echo вообще не может быть использована абсолютно безопасно. Если переменная содержит только два символа “-n”, команда echo будет рассматривать их как опцию, а не как данные, которые нужно вывести на печать, и абсолютно ничего не выведет. Единственный надёжный способ напечатать значение переменной — воспользоваться командой printf:

printf "%sn" "$foo"

13. $foo=bar

Нет, вы не можете создать переменную, поставив “$” в начале её названия. Это не Perl. Достаточно написать:

foo=bar

14. foo = bar

Нет, нельзя оставлять пробелы вокруг “=”, присваивая значение переменной. Это не C. Когда вы пишете foo = bar, оболочка разбивает это на три слова, первое из которых, foo, воспринимается как название команды, а оставшиеся два — как её аргументы.

По этой же причине нижеследующие выражения также неправильны:

foo= bar    # НЕПРАВИЛЬНО!
foo =bar    # НЕПРАВИЛЬНО!
$foo = bar  # АБСОЛЮТНО НЕПРАВИЛЬНО!
 
foo=bar     # Правильно.

15. echo <<EOF

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

# Неправильно:
echo <<EOF
Hello world
EOF
 
# Правильно:
cat <<EOF
Hello world
EOF

16. su -c ’some command’

В Linux этот синтаксис корректен и не вызовет ошибки. Проблема в том, что в некоторых системах (например, FreeBSD или Solaris) аргумент -c команды su имеет совершенно другое назначение. В частности, в FreeBSD ключ -c указывает класс, ограничения которого применяются при выполнении команды, а аргументы шелла должны указываться после имени целевого пользователя. Если имя пользователя отсутствует, опция -c будет относиться к команде su, а не к новому шеллу. Поэтому рекомендуется всегда указывать имя целевого пользователя, вне зависимости от системы (кто знает, на каких платформах будут выполняться ваши скрипты…):

su root -c 'some command' # Правильно.

17. cd /foo; bar

Если не проверить результат выполнения cd, в случае ошибки команда bar может выполниться не в том каталоге, где предполагал разработчик. Это может привести к катастрофе, если bar содержит что-то вроде rm *.

Поэтому всегда нужно проверять код возврата команды «cd». Простейший способ:

cd /foo && bar

Если за cd следует больше одной команды, можно написать так:

cd /foo || exit 1
bar
baz
bat ... # Много команд.

cd сообщит об ошибке смены каталога сообщением в stderr вида bash: cd: /foo: No such file or directory. Если вы хотите вывести своё сообщение об ошибке в stdout, следует использовать группировку команд:

cd /net || { echo "Can't read /net.  Make sure you've logged in to the Samba network, and try again."; exit 1; }
do_stuff
more_stuff

Обратите внимание на пробел между { и echo, а также на точку с запятой перед закрывающей }.

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

Кстати, если вы много работаете с директориями в bash-скрипте, перечитайте man bash в местах, относящихся к командам pushd, popd и dirs. Возможно, весь ваш код, напичканный cd и pwd, просто не нужен :).

Вернёмся к нашим баранам. Сравните этот фрагмент:

find ... -type d | while read subdir; do
cd "$subdir" && whatever && ... && cd -
done

с этим:

find ... -type d | while read subdir; do
(cd "$subdir" && whatever && ...)
done

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

Кроме того, предпоследний пример содержит ещё одну ошибку: если одна из команд whatever провалится, мы можем не вернуться обратно в начальный каталог. Чтобы исправить это без использования субшелла, в конце каждой итерации придётся делать что-то вроде cd «$ORIGINAL_DIR», а это добавит ещё немного путаницы в ваши скрипты.

18. [ bar == «$foo» ]

Оператор == не является аргументом команды [. Используйте вместо него = или замените [ ключевым словом [[:

[ bar = "$foo" ] && echo yes
[[ bar == $foo ]] && echo yes

19. for i in {1..10}; do ./something &; done

Нельзя помещать точку с запятой “;” сразу же после &. Просто удалите этот лишний символ:

for i in {1..10}; do ./something & done

Символ & сам по себе является признаком конца команды, так же, как “;” и перевод строки. Нельзя ставить их один за другим.

20. cmd1 && cmd2 || cmd3

Многие предпочитают использовать && и || в качестве сокращения для if … then … else … fi. В некоторых случаях это абсолютно безопасно:

[[ -s $errorlog ]] && echo "Uh oh, there were some errors." || echo "Successful."

Однако в общем случае эта конструкция не может служить полным эквивалентом if … fi, потому что команда cmd2 перед && также может генерировать код возврата, и если этот код не 0, будет выполнена команда, следующая за ||. Простой пример, способный многих привести в состояние ступора:

i=0
true && ((i++)) || ((i--))
echo $i   # выведет 0

Что здесь произошло? По идее, переменная i должна принять значение 1, но в конце скрипта она содержит 0. То есть последовательно выполняются обе команды i++ и i–. Команда ((i++)) возвращает число, являющееся результатом выполнения выражения в скобках в стиле C. Значение этого выражения — 0 (начальное значение i), но в C выражение с целочисленным значением 0 рассматривается как false. Поэтому выражение ((i++)), где i равно 0, возвращает 1 (false) и выполняется команда ((i–)).

Этого бы не случилось, если бы мы использовали оператор преинкремента, поскольку в данном случае код возврата ++i — true:

i=0
true && (( ++i )) || (( --i ))
echo $i    # выводит 1

Но нам всего лишь повезло и наш код работает исключительно по “случайному” стечению обстоятельств. Поэтому нельзя полагаться на x && y || z, если есть малейший шанс, что y вернёт false (последний фрагмент кода будет выполнен с ошибкой, если i будет равно -1 вместо 0)

Если вам нужна безопасность, или вы сомневаетесь в механизмах, которые заставляют ваш код работать, или вы ничего не поняли в предыдущих абзацах, лучше не ленитесь и пишите if … fi в ваших скриптах:

i=0
if true; then
((i++))
else
((i--))
fi
echo $i   # выведет 1.

Bourne shell это тоже касается:

# Выполняются оба блока команд:
$ true && { echo true; false; } || { echo false; true; }
true
false

21. Касательно UTF-8 и BOM (Byte-Order Mark, метка порядка байтов)

В общем: в Unix тексты в кодировке UTF-8 не используют метки порядка байтов. Кодировка текста определяется по локали, mime-типу файла, или по каким-то другим метаданным. Хотя наличие BOM не испортит UTF-8 документ в плане его читаемости человеком, могут возникнуть проблемы с автоматической интерпретацией таких файлов в качестве скриптов, исходных кодов, файлов конфигурации и т.д. Файлы, начинающиеся с BOM, должны рассматриваться как чужеродные, так же как и файлы с DOS’овскими переносами строк.

В шелл-скриптах: «Там, где UTF-8 может прозрачно использоватся в 8-битных окружениях, BOM будет пересекаться с любым протоколом или форматом файлов, предполагающим наличие символов ASCII в начале потока, например, #! в начале шелл-скриптов Unix» ://unicode.org/faq/utf_bom.html#bom5

22. echo «Hello World!»

Проблема в том, что в интерактивной оболочке Bash эта команда вызовет ошибку:

bash: !": event not found

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

Очевидное решение здесь не работает:

$ echo "hi!"
hi!

Можно заключить эту строку в одинарные кавычки:

echo 'Hello World!'

Но самое подходящее решение здесь — временно выключить параметр histexpand. Это можно сделать командой set +H или set +o histexpand:

set +H
echo "Hello World!"

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

mp3info -t "Don't Let It Show" ...
mp3info -t "Ah! Leah!" ...

Одинарные кавычки здесь не подходят, поскольку названия песен содержат апострофы в названиях, а использование двойных кавычек приведёт к проблеме с подстановкой истории команд (а если бы в именах файлов ещё и двойные ковычки содержались, получилось бы вообще черте что). Поскольку лично я (Greg Wooledge, автор текста) никогда не использую подстановку истории команд, я просто поместил команду set +H в свой .bashrc. Но это вопрос привычки и каждый решает для себя сам.

23. for arg in $*

В Bash’е, так же, как и в других оболочках семейства Bourne shell, есть специальный синтаксис для работы с позиционными параметрами по очереди, но $* и $@ не совсем то, что вам нужно: после подстановки параметров они становятся списком слов, переданных в аргументах, а не списком параметров по отдельности.

Вот правильный синтаксис:

for arg in "$@"

Или просто:

for arg

for arg соответствует for arg in «$@». Заключенная в двойные кавычки переменная «$@» — это специальная уличная магия, благодаря которой каждый аргумент командной строки заключается в двойные кавычки, так что он выглядит как отдельное слово. Другими словами, «$@» преобразуется в список «$1» «$2» «$3» и т.д. Этот трюк подойдёт в большинстве случаев.

Рассмотрим пример:

#!/bin/bash
# неправильно
for x in $*; do
echo "parameter: '$x'"
done

Этот код напечатает:

$ ./myscript 'arg 1' arg2 arg3
parameter: 'arg'
parameter: '1'
parameter: 'arg2'
parameter: 'arg3'

Вот как это должно выглядеть:

#!/bin/bash
# правильно!
for x in "$@"; do
echo "parameter: '$x'"
done
 
$ ./myscript 'arg 1' arg2 arg3
parameter: 'arg 1'
parameter: 'arg2'
parameter: 'arg3'

24. function foo()

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

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

foo() {
...
}

25. echo «~»

Замена тильды (tilde expansion) происходит только когда символ ~ не окружён кавычками. В этом примере echo выведет ~ в stdout, вместо того, чтобы вывести пользовательский домашний каталог.

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

"~/dir with spaces"       #  "~/dir with spaces"
~"/dir with spaces"       # "~/dir with spaces"
~/"dir with spaces"       # "/home/my photos/dir with spaces"
"$HOME/dir with spaces"   # "/home/my photos/dir with spaces"

26. local varname=$(command)

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

Поэтому эти команды лучше разделять:

local varname
varname=$(command)
rc=$?

Изучаем возможности директории /proc

Перевод статьи Federico Kereki «Discover the possibilities of the /proc directory».

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

В Linux все представлено в виде файла; даже к устройствам доступ происходит, как к файлам (в директории /dev). Не смотря на то, что вы можете подумать, что «нормальные» файлы либо текстовые, либо бинарные (или, возможно, файлы устройств или конвейеров), директория /proc содержит файлы странного типа, — виртуальные файлы. Их можно вывести списком, но на самом деле, они не существуют на диске; операционная система создает их «на лету», если вы делаете попытку их прочитать.

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

Организация директории /proc

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

1     2432  3340  3715  3762  5441  815
 
129   2474  3358  3716  3764  5445
 
1290  248   3413  3717  3812  5459
 
133   2486  3435  3718  3813  5479
 
1420  2489  3439  3728  3814  557
 
165   276   3450  3731  39    5842
 
166   280   36    3733  3973  5854
 
2     2812  3602  3734  4     6
 
2267  3     3603  3735  40    6381
 
2268  326   3614  3737  4083  6558
 
2282  327   3696  3739  4868  6561
 
2285  3284  3697  3742  4873  6961
 
2295  329   3700  3744  4878  7206
 
2335  3295  3701  3745  5     7207
 
2400  330   3706  3747  5109  7222
 
2401  3318  3709  3749  5112  7225
 
2427  3329  3710  3751  541   7244
 
2428  3336  3714  3753  5440  752
 
devices      modules
 
acpi       diskstats    mounts
 
asound     dma          mtrr
 
bus        execdomains  partitions
 
dri        fb           self
 
driver     filesystems  slabinfo
 
fs         interrupts   splash
 
ide        iomem        stat
 
irq        ioports      swaps
 
net        kallsyms     sysrq-trigger
 
scsi       kcore        timer_list
 
sys        keys         timer_stats
 
sysvipc    key-users    uptime
 
tty        kmsg         version
 
buddyinfo  loadavg      vmcore
 
cmdline    locks        vmstat
 
config.gz  meminfo      zoneinfo
 
cpuinfo    misc

Пронумерованные директории (остановимся на них позже) соответствуют каждому запущенному процессу; специальная символьная ссылка self указывает на текущий процесс. Некоторые виртуальные файлы предоставляют информацию о аппаратном обеспечении, например, /proc/cpuinfo, /proc/meminfo и /proc/interrupts. Другие дают информацию, связанную с файлами, например, /proc/filesystems или /proc/partitions. Файлы в /proc/sys относятся к конфигурации параметров ядра, как мы увидим позже.

Команда cat /proc/meminfo может дать следующее:

# cat /proc/meminfo
 
MemTotal:       483488 kB
 
MemFree:          9348 kB
 
Buffers:          6796 kB
 
Cached:         168292 kB
 
...несколько строк пропущены...

Если вы попробуете команды top или free, вы можете узнать некоторые из этих чисел. Фактически, несколько хорошо известных утилит получают доступ к директории /proc, чтобы получить информацию. Например, если вы хотите узнать, какую версию ядра вы используете, вы можете попробовать uname -srv или спуститься к истокам и набрать cat /proc/version. Есть ещё несколько других интересных файлов:

/proc/apm: содержит информацию о Advanced Power Management, если она установлена.

/proc/acpi: похожая директория, дающая хорошую информацию про более современный ACPI. К примеру, чтобы узнать, подключен ли ваш ноутбук к питанию AC, вы можете выполнить cat /proc/acpi/ac_adapter/AC/state и получить либо «on line», либо «off line»

/proc/cmdline: Показывает параметры, переданные ядру при загрузке. В моем случае, это root=/dev/disk/by-id/scsi-SATA_FUJITSU_MHS2040_NLA5T3314DW3-part3 vga=0x317 resume=/dev/sda2 splash=silent PROFILE=QuintaWiFi, что говорит о том, какой раздел файловой системы является основным, какой режим VGA используется и так далее. Последний параметр сделан с помощью Системы управления настройкой провилей openSUSE.

/proc/cpuinfo: Дает данные о процессоре вашего компьютера. Например, на моем ноутбуке, команда cat /proc/cpuinfo выводит листинг, начинающийся с:

processor       : 0
 
vendor_id       : AuthenticAMD
 
cpu family      : 6
 
model           : 8
 
model name      : Mobile AMD Athlon(tm) XP 2200+
 
stepping        : 1
 
cpu MHz         : 927.549
 
cache size      : 256 KB

Демонстрирующий, что у меня есть только один процессор, под номером 0, семейства 80686 (6 в cpu family идет в качестве средней цифры), — AMD Athlon XP, работающий минимум на 1 Гц.

/proc/loadavg: Файл, показывающий среднюю загрузку процессора; его информация включает использование ЦПУ в последнюю минуту, последние пять минут и последние 10 минут, а также число процессов, работающих в данный момент.

/proc/stat: Также предоставляет статистику, но последней загрузки.

/proc/uptime: Короткий файл, в котором только два числа — сколько секунд ваша система работает и сколько секунд она простаивает.

/proc/devices: Показывает все настроенные и загруженные символьные и блочные устройства. /proc/ide и /proc/scsi дает данные об устройствах IDE и SCSI.

/proc/ioports: Показывает информацию о зонах, используемых для ввода-вывода с вышеуказанными устройствами.

/proc/dma: Показывает используемые каналы DMA.

/proc/filesystems: Показывает типы файловых систем, поддерживаемых вашим ядром. Вот как это может выглядеть:

nodev   sysfs
 
nodev   rootfs
 
nodev   bdev
 
nodev   proc
 
nodev   cpuset
 
...несколько строк пропущено...
 
nodev   ramfs
 
nodev   hugetlbfs
 
nodev   mqueue
 
       ext3
 
nodev   usbfs
 
       ext2
 
nodev   autofs

Первая колонка показывает, какая файловая система монтирована на блочное устройство. В моем случае, у меня есть разделы, настроенные с смонтированными ext2 и ext3.

/proc/mounts: Показывает всё смонтированное, что используется вашим компьютером (его вывод очень похож на /etc/mtab). Проще говоря, /proc/partitions и /proc/swaps покажет все разделы и пространство swap.

/proc/fs: Если вы открываете общий доступ к файловым системам с помощью NFS, в этой директории среди множества поддиректорий и файлов, есть /proc/fs/nfsd/exports, который показывает файловую систему, открытую для общего доступа и права на неё.

/proc/net: Содержит сетевую информацию. Описание каждого из файлов в этой директории займет слишком много места, но в ней есть /dev (каждое сетевое устройство), несколько файлов, связанных с iptables, сетевая статистика и статистика портов, информация о беспроводных подключениях и так далее.

Есть также несколько файлов, связанных с ОЗУ. Я уже упомянул о /proc/meminfo, но у вас также есть /proc/iomem, который показывает, сколько памяти использует ваша система и /proc/kcore, демонстрирующий физическую оперативную память ваше системы. В отличие от большинства других виртуальных файлов, размер /proc/kcore соответствует размеру вашей оперативной памяти и даже немного больше (не пытайтесь выполнить cat /proc/kcore, так как он имеет бинарное содержимое и завалит ваш экран). Наконец, здесь же есть много файлов и директорий, связанных с аппаратным обеспечением, такие как /proc/interrupts и /proc/irq, /proc/pci (все устройства PCI), /proc/bus и так далее, но они включают в себя очень специфическую информацию, которая не нужна большинству пользователей.

Что с процессами?

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

attr             cpuset   fdinfo
 
auxv             cwd      loginuid
 
clear_refs       environ  maps
 
cmdline          exe      mem
 
coredump_filter  fd       mounts
 
mountstats  stat
 
oom_adj     statm
 
oom_score   status
 
root        task
 
smaps       wchan

Давайте изучим основные файлы:

cmdline: Содержит команду, запустившую процесс, со всеми её параметрами.

cwd: Символьная ссылка на текущую рабочую директорию (CWD) процесса; exe ссылается на исполняемый процесс, а root на его корневую директорию.

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

fd: Содержит все файловые дескрипторы для процесса, показывающие, какие файлы или устройства он использует.

maps, statm и mem: Работают с памятью, используемой процессом.

stat и status: Предоставляют информацию о статусе процесса, но последний — более четкую и упорядоченную.

Эти файлы дают несколько возможностей для написания скриптов. Например, если вы хотите отследить процессы-зомби, вы можете пройти по всем пронумерованным директориям и проверить содержание строки «(Z) Zombie» в файле /status. Однажды мне надо было проверить, запущена ли определенная программа. Я сделал проход по директориям и проверил файлы /cmdline, в поисках необходимой строки (вы также можете сделать это с помощью команды ps, но в этой статье это не рассматривается). А если вы хотите написать top, который будет выглядеть лучше, вся необходимая информация в ваших руках.

Настройка системы: /proc/sys

/proc/sys не только дает информацию о системе, она также позволяет изменять параметры ядра «на лету», активируя и дезактивируя его возможности (конечно, это может принести и вред вашей системе, — будьте осторожны!).

Чтобы определить, какой файл для настройки, а какой только для чтения, выполните ls -ld. Если файл имеет аттрибут «W», это значит, что вы можете использовать его каким-либо образом для настройки ядра. К примеру, ls -ld /proc/kernel/* начинается примерно так:

dr-xr-xr-x 0 root root 0 2008-01-26 00:49 pty
 
dr-xr-xr-x 0 root root 0 2008-01-26 00:49 random
 
-rw-r--r-- 1 root root 0 2008-01-26 00:49 acct
 
-rw-r--r-- 1 root root 0 2008-01-26 00:49 acpi_video_flags
 
-rw-r--r-- 1 root root 0 2008-01-26 00:49 audit_argv_kb
 
-r--r--r-- 1 root root 0 2008-01-26 00:49 bootloader_type
 
-rw------- 1 root root 0 2008-01-26 00:49 cad_pid
 
-rw------- 1 root root 0 2008-01-26 00:49 cap-bound

Как видете, bootloader_type не может быть изменен, но остальные файлы могут. Чтобы изменить файл, используйте что-то вроде echo 10 >/proc/sys/vm/swappiness. Конкретно этот пример позволит вам настроить производительность страничной организации виртуальной памяти. Кстати, эти изменения — временные и их результаты будут отменены при перезагрузке. Используйте sysctl и файл /etc/sysctl.conf, чтобы сделать более постоянные изменения.

Давайте поверхностно посмотрим на директории в /proc/sys:

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

dev: Предоставляет информацию о специфических устройствах в вашей системе. Например, проверьте директорию /dev/cdrom.

fs: Дает данные о каждом возможном аспекте файловой системы.

kernel: Позволяет вам затрагивать работу и настройки ядра напрямую.

net: Допускает вас до вопросов, связанных с сетью. Будьте осторожны, потому как запутавшись в этом, вы можете потерять подключение.

vm: Работает с подсистемой VM.

Заключение

Специальная директория /proc предоставляет детальную информацию о внутренней работе Linux и позволяет вам улучшить многие аспекты его настройки. Если вы потратите немного больше времени, изучая все возможности этой директории, вы сможете получить более совершенную систему Linux. А не этого ли мы все желаем?

Советы по работе с DNS зонами

Чтобы было наглядней о чем разговор идет, опишу как происходит процесс делегирования. Делегирование — это то каким образом пространство имен в DNS делится на зоны. Зона — это обособленная ветвь пространства DNS имен которая располагается на своих авторитарных DNS серверах. В зону может входить любое количество доменов нижележащего уровня — до тех пор пока они все расположены на одних и тех же авторитарных серверах, зона у них одна и та же.
Делегирование из родительской зоны происходит путем создания NS записей. В дочерней (делегированной) зоне создается полное описание зоны начиная с SOA записи. Вот, например, когда регистрируется домен второго уровня через регистратора nic.ru, то там при регистрации просят указать имена и адреса минимум двух DNS серверов которые будут считаться авторитарными для данной ветви пространства DNS имен. Для проведения делегирования не обязательно иметь под зону именно два DNS сервера — просто у nic.ru такая политика для того чтобы заставить клиентов обеспечить надежность системы. Вот эти два сервера становятся NS записями в домене ru.

Пример. Скажем, нами регистрируется домен второго уровня под названием net.ru. Авторитарными для него будут DNS сервера ns.net.ru (IP 1.2.3.4) и ns2.dnshosting.com (IP 5.6.7.9). В записях DNS серверов отвечающих за зону ru. (которыми управляет организация nic.ru) вносится такая информация:

$TTL 300
ru.   IN   SOA   ns.ripn.net. hostmaster.ripn.net. (
         4014396 ;serial
         7200   ;refresh
         900   ;retry
         2592000   ;expire
         3600   ;neg. ttl
         )
      NS   sunic.sunet.se.
      NS   e.dns.ripn.net.
      NS   ns.ripn.net.
      NS   ns5.msk-ix.net.
 
; это добавили
net.ru.   NS   ns.net.ru.
net.ru.   NS   ns2.dnshosting.com.
ns.net.ru.   A   1.2.3.4

Запись «ns.net.ru. A 1.2.3.4» называют еще «glue record», она нужна в случаях, когда имя NS сервера располагается внутри делегированной зоны. Это вспомогательная запись которую обязательно указывать в таких случаях. Без нее возникла бы ситуация, когда для того чтобы узнать IP сервера ns.net.ru надо обратиться к нему по IP (замкнутый круг). Так как второй NS расположен в чужой зоне, то для него не указываем glue record.

В свою очередь на сервере ns.net.ru который является мастером для зоны net.ru создается полная SOA запись как и полагается:

$TTL 300
net.ru.   IN   SOA   ns.net.ru. hostmaster.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
      MX 10   mail.net.ru.
ns.net.ru.   A   1.2.3.4
 
www.net.ru.   A   9.8.7.6
ftp.net.ru.   A   10.11.12.13
mail.net.ru.   A   11.12.13.14

На slave сервере ns2.dnshosting.com в ручную записи не создаются, но он настраивается так чтобы периодически запрашивать мастер ns.net.ru и перекачивать с него всю информацию о записях в домене, а мастер ns.net.ru настраивается так чтобы отдавать все записи о зоне при запросах с подчиненного.

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

Например случай с делегированием домена третьего уровня. Выглядеть это будет так — в записях зоны net.ru добавляется информация с NS записями о субдомене home.net.ru (допустим, будет только один авторитарный DNS сервер для этого субдомена ns.home.net.ru IP 7.7.7.7)

$TTL 300
net.ru.   IN   SOA   ns.net.ru. hostmaster.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
      MX 10   mail.net.ru.
ns.net.ru.   A   1.2.3.4
 
www.net.ru.   A   9.8.7.6
ftp.net.ru.   A   10.11.12.13
mail.net.ru.   A   11.12.13.14
 
;это добавили
home.net.ru.   NS   ns.home.net.ru.
ns.home.net.ru.   A   7.7.7.7

Ну и соответственно на DNS сервере ns.home.net.ru создается зона с новой SOA записью:

$TTL 300
home.net.ru.   IN   SOA   ns.home.net.ru. adminzoni.mail.ru. (
         2009012501   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.home.net.ru.
ns.home.net.ru.   A   7.7.7.7
 
home.net.ru.      A   7.7.7.8
www.home.net.ru.   A   7.7.7.8
proxy.home.net.ru.   A   7.7.7.9

Был приведен синтаксис зоны как это принято в BIND и NSD. Для djbdns то, что написано выше будет выглядеть так:

Zhome.net.ru:ns.home.net.ru.:adminzoni.mail.ru.: \
2009012501:7200:900:2592000:3600:300
&amp;home.net.ru:7.7.7.7:ns.home.net.ru
+home.net.ru:7.7.7.8:300
+www.home.net.ru:7.7.7.8:300
+proxy.home.net.ru:7.7.7.9:300

До кучи, напишу заодно еще и про реверс зоны и их делегирование.
Система DNS позволяет производить обратные разрешения из IP адресов в DNS имена. Для этого в дереве имен есть специальный служебный домен под именем in-addr.arpa. Этот домен имеет 256 субдоменов, каждый из субдомменов может иметь 256 своих субдоменов, у которых могут быть 256 своих субдоменов, в которых уже будет по 256 имен. Таким образом получается структура вида a.b.c.d.in-addr.arpa. где а,b,c,d это 0-255. На эту часть DNS имен распространяются те же правила, что и на обычные имена, вот только владельцем какого-либо субдомена может стать лишь организация получившая контроль за соответствующим блоком IP адресов — например провайдер, когда покупает для своих нужд у RIPE диапазоны IP адресов. Например, если провайдер купил себе префикс с адресами 123.44.55.0/24 (256 адресов), то он может получить от RIPE (регионального регистратора) и реверс зону в которой начнет создавать PTR записи по просьбе клиентов или для своих нужд:

$TTL 300
55.44.123.in-addr.arpa.   IN   SOA   ns.net.ru. admin.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
 
1.55.44.123.in-addr.arpa.   PTR   hostname.net.ru.
2.55.44.123.in-addr.arpa.   PTR   imja.net.ru.
254.55.44.123.in-addr.arpa.   PTR   esheodnoija.net.ru.

Тут все просто и красиво потому, что в этом примере деление на DNS зону и IP субнет произошло по границе третьего и четвертого байта в IP адресе, а как делегировать половину субнета или только пару IP адресов из него? Скажем, клиент купил себе 8 «белых» IP адресов и захотел получить контроль над назначением реверс имен для них?
В таком случае можно сделать делегирование таким образом — в родительской зоне создаются CNAME записи на подставной домен, а он уже делегируется клиенту:

$TTL 300
55.44.123.in-addr.arpa.   IN   SOA   ns.net.ru. admin.net.ru. (
         2009012500   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.net.ru.
      NS   ns2.dnshosting.com.
 
1.55.44.123.in-addr.arpa.   PTR   hostname.net.ru.
2.55.44.123.in-addr.arpa.   PTR   imja.net.ru.
254.55.44.123.in-addr.arpa.   PTR   esheodnoija.net.ru.
 
;создаем подставные записи
7.55.44.123.in-addr.arpa.   CNAME   7.klient.55.44.123.in-addr.arpa.
8.55.44.123.in-addr.arpa.   CNAME   8.klient.55.44.123.in-addr.arpa.
9.55.44.123.in-addr.arpa.   CNAME   9.klient.55.44.123.in-addr.arpa.
10.55.44.123.in-addr.arpa.   CNAME   10.klient.55.44.123.in-addr.arpa.
11.55.44.123.in-addr.arpa.   CNAME   11.klient.55.44.123.in-addr.arpa.
12.55.44.123.in-addr.arpa.   CNAME   12.klient.55.44.123.in-addr.arpa.
13.55.44.123.in-addr.arpa.   CNAME   13.klient.55.44.123.in-addr.arpa.
14.55.44.123.in-addr.arpa.   CNAME   14.klient.55.44.123.in-addr.arpa.
 
;делегируем клиенту
klient.55.44.123.in-addr.arpa.   NS   ns1.klient.ru.
klient.55.44.123.in-addr.arpa.   NS   ns2.hosting.com.

Клиент принимает у себя:

$TTL 300
klient.55.44.123.in-addr.arpa.   IN   SOA   ns.klient.ru. admin.klient.ru. (
         2009012502   ;serial
         7200      ;refresh
         900      ;retry
         2592000      ;expire
         3600      ;neg. ttl
         )
      NS   ns.klient.ru.
      NS   ns2.hosting.com.
 
7.klient.55.44.123.in-addr.arpa.   PTR   host1.klient.ru.
8.klient.55.44.123.in-addr.arpa.   PTR   host2.klient.ru.
9.klient.55.44.123.in-addr.arpa.   PTR   host3.klient.ru.
10.klient.55.44.123.in-addr.arpa.   PTR   host4.klient.ru.
11.klient.55.44.123.in-addr.arpa.   PTR   host5.klient.ru.
12.klient.55.44.123.in-addr.arpa.   PTR   host6.klient.ru.
13.klient.55.44.123.in-addr.arpa.   PTR   host7.klient.ru.
14.klient.55.44.123.in-addr.arpa.   PTR   host8.klient.ru.
 
...

Да, еще одна штука вспомнилась.
Я когда работал в провайдере, так все хотел приколоться и сделать себе почтовый адрес вида terminus@1.2.3.4.in-addr.arpa, но не успел — все лень было, а потом уволился и сейчас своих реверс зон нет нигде.

Между прочим, нету никакаих объективных причин почему бы такое не работало — DNS должен будет корректно отвечать на запросы о MX записях для домена 1.2.3.4.in-addr.arpa так же как и для обычных доменов. Если есть в наличии SMTP сервер «для поиграться» + желание приколоться, то можно прописать в PTR зоне MX запись, на почтовом сервере на который указывают MX запись прописать домен, и проверить как оно будет (99% что должно работать).

Источник