Очистіть вміст файлу

Мені відомо три способи видалення всіх записів з файлу.

Вони є

• >filename
• touch filename
• filename < /dev/null

З цих трьох я зловживаю >filenameнайбільше, оскільки для цього потрібна найменша кількість натискань клавіш.

Однак я хотів би знати, який найбільш ефективний із цих трьох (якщо є якісь більш ефективні методи) щодо великих журналів і малих файлів.

Крім того, як три коди діють та видаляють вміст?

Насправді друга форма touch filenameнічого не видаляє з файлу - вона створює лише порожній файл, якщо такого не існувало, або оновлює останню змінену дату існуючого файлу.

І третя filename < /dev/nullнамагається запустити ім'я файлу з /dev/nullвведенням.

cp /dev/null filename працює.

Щодо ефективного, найефективнішим було б truncate -s 0 filename; дивіться тут: http://linux.die.net/man/1/truncate .

В іншому випадку cp /dev/null filenameабо > filenameобидва штрафу. Вони обидва відкривають, а потім закривають файл, використовуючи налаштування усікання-відкривання. cpтакож відкривається /dev/null, так що робить це незначно повільніше.

З іншого боку, truncateце, швидше за все, буде повільніше, ніж > filenameпри запуску зі скрипту, оскільки виконання команди усікання вимагає від системи відкрити виконуваний файл, завантажити його та запустити його.

Іншим варіантом може бути:

echo -n > filename

З чоловічої сторінки echo:

-n Do not print the trailing newline character.

Існує вбудована команда ":", яка доступна в sh, csh, bash та інших, можливо, яка може бути легко використана разом із >усіма файлами оператора перенаправлення виводу :

#!/usr/bin/env bash
:> filename

Мені подобається, що для цього не потрібні зовнішні команди, такі як "ехо" тощо.

Однією з головних переваг обрізання файлів замість видалення / відтворення їх є те, що запущені програми, які працюють з цим файлом (наприклад, хтось робить tail -f filenameпрограмне забезпечення для моніторингу, ...) не повинні його знову відкривати. Вони просто можуть продовжувати використовувати fileescriptor і отримувати всі нові дані.