Чому ви б "cat / dev / null> / var / log / messages"?

На цій прикладі баш сценаріїв автор представляє цей сценарій:

# Cleanup
# Run as root, of course.

cd /var/log
cat /dev/null > messages
cat /dev/null > wtmp
echo "Log files cleaned up."

Навіщо ви хотіли cat /dev/nullщось робити? Я не можу зрозуміти , що тут призначене (це як використання while TRUE; sleep 1; elihwдля {some busy program}?). Але автор називає це «Нічого незвичайного».

Зазвичай, cat /dev/null > [something]коли ви хочете стерти вміст файлу, гарантуючи, що існує абсолютно нульовий ризик переривання фактичного стану файлу. Вміст файлу буде чітко стертий cat /dev/nullще самим файлом - як він існує, так і відомий файловій системі, на якій він перебуває - все ще буде там з тим самим номером inode, правом власності та дозволами.

У випадку з файлом журналу може бути, що сам файл журналу позначений "використовується" іншим процесом. Так що, наприклад, - rm /var/log/messages && touch /var/log/messagesможе бути руйнівним для інших процесів і може призвести до задушення запущених процесів. Це означає, що процес, який якимось чином заблокований у певному номері inode, підключеному до файлу, /var/log/messagesможе раптом панікувати і сказати: "Ей! Що трапилось /var/log/messages! ”Навіть якщо файл все ще є. Не кажучи вже про можливі проблеми з неправильним відтворенням прав власності та дозволів.

Через цю невизначеність у використанні / стані файлу використання cat /dev/null > [something]системного адмініструвальника надають перевагу використанню, які хочуть очистити журнал, але не хочуть потенційно заважати роботі вже існуючих процесів.

Також у контексті сторінки, яку ви посилаєтесь на автора, зазначено наступне:

Тут немає нічого незвичайного, лише набір команд, які так само легко можна було викликати по черзі з командного рядка на консолі чи у вікні терміналу. Переваги розміщення команд у сценарії виходять далеко за межі того, що не потрібно їх повторно вводити повторно.

Отже, "нічого незвичайного" автор згадує, що стосується цілого поняття, що таке конкретний скрипт bash: Це лише набір простих команд, які так само легко можна запустити з командного рядка, але розмістити у текстовому файлі для уникати повторного введення їх знову і знову.

Чому б ти котів / dev / null ні на що?

Ви зробите це для врізання вмісту файлу, зберігаючи inode недоторканою. Усі програми, у яких цей файл відкритий для читання чи запису, не впливатимуть поза тим, що розмір файлу буде скинутий до нуля.

Часто зустрічається хибна альтернатива - це видалити файл, а потім створити його знову:

rm file
touch file

або подібне:

mv file file.old
gzip file.old
touch file

Проблема полягає в тому, що ці методи не перешкоджають збереженню старого файлу будь-якими процесами, що видаляють файл, відкритий під час видалення. Причина, чому знаходиться під файловими системами Unix, коли ви видаляєте файл, ви лише від'єднуєте його ім’я (шлях) від його вмісту (inode). Інода зберігається живою, доки є процеси, відкриті для читання чи письма.

Це призводить до декількох негативних ефектів: журнали, написані після видалення файлу, втрачаються, оскільки не існує прямого / портативного способу відкрити видалений файл. Поки процес записується до видаленого файлу, його вміст все ще використовує простір у файловій системі. Це означає, що якщо ви видалите / створите файл, оскільки він заповнював ваш диск, диск залишається заповненим. Один із способів виправити цю останню проблему - це перезапустити процеси реєстрації, але ви, можливо, не захочете цього робити для критичних служб і журналів посередників остаточно втратяться. Існують також побічні ефекти, зумовлені тим, що створений вами файл може не мати таких самих дозволів, власника та групи, як оригінальний. Це, наприклад, може завадити аналізатору журналу читати новостворений файл, або ще гірше, запобігти процесу реєстрації записів власних журналів.

Перший метод - cat /dev/null > fileдосягти мети належним чином, проте, незважаючи на завзяту міську легенду, його cat /dev/nullчастина не робить нічого корисного. Він відкриває псевдофайл, який порожній за дизайном, не вдається прочитати з нього нічого і, нарешті, просто виходить. Використання цієї команди - це марно натискання клавіш, байтів, системних викликів та циклів процесора, і його можна без будь-яких функціональних змін замінити, безсумнівно, швидшою командою без операції :або навіть, з більшості оболонок, зовсім не командою.

Дозвольте спробувати метафору, щоб пояснити, наскільки це марно cat /dev/null. Скажімо, ваша мета - спорожнити склянку.

• Спочатку ви виймаєте з нього будь-яку рідину. Цього достатньо і саме те, що ( > file) робить з огляду на те, що перенаправлення завжди обробляються першими.

• Потім ви вибираєте порожню пляшку ( /dev/null) і наливаєте її в порожню склянку ( cat). Це безглуздий крок ...

Якщо ви прочитаєте зв'язаний документ до кінця, ви можете помітити коментарі в цьому рядку з розширеної версії сценарію:

    cat / dev / null> wtmp #   ':> wtmp' і '> wtmp' мають однаковий ефект.

Вони справді є; занадто погано cat /dev/nullзберігалося в коді.

Це означає, що наступний код буде працювати з усіма загальними оболонками ( cshі shсім'ями):

cd /var/log
: > messages
: > wtmp
echo "Log files cleaned up."

і це буде працювати з усіма оболонками , використовуючи синтаксис Bourne, як ash, bash, ksh, zshі любить:

cd /var/log
> messages
> wtmp
echo "Log files cleaned up."

Однак зауважте, що з давніми, перед-POSIX оболонками Борна, будь-яка з цих команд, включаючи cat /dev/null, не буде усікати файл, якщо він буде записаний згодом ще доданим до нього сценарієм оболонки. Замість файлу з нульовим байтом це був би розріджений файл з його розміром незмінним. Те ж саме сталося б, якщо файл записується процесом, який шукає положення, яке, на його думку, є поточним перед написанням.

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

• Обидва наступні просто не виконують завдання. Отриманий файл не порожній, але містить порожній рядок. Це порушить файли журналів, як wtmp, наприклад , зберігають записи фіксованої ширини.

  echo > file
  echo "" > file

• Наступний варіант, заснований на BSD- shопції, не є портативним, POSIX не вказує жодних дозволених параметрів для відлуння, тому, можливо, ви отримаєте файл, що містить рядок з " -n":

  echo -n > file

• Той, що не є портативним, також використовуючи shпослідовність аварійної системи System V. Деякі оболонки створять файл, що містить рядок з " \c":

  echo "\c" > file

• Цей користується командою, призначеною для виконання завдання. Проблема з використанням truncateне є портативною, оскільки ця команда, не визначена POSIX, може бути відсутня у системі Unix / Linux.

  truncate -s 0

Нарешті, ось кілька альтернативних варіантів, які є портативними та належним чином виконають роботу:

• Явно друкує порожній рядок у файл:

  printf "" > file

• Використання trueкоманди, яка суворо еквівалентна no-op, :хоч і читабельніше:

  true > file

Це громіздкий спосіб довести файл до нульового розміру.

cd /var/log
> messages
> wtmp
echo "Log files cleaned up."

Щоб урізати відкритий файл. Це рівнозначно і зрозуміліше:

echo -n > /var/log/messages

(Додано -n, щоб уникнути нового рядка)