Комментарии 23
Решение с временным файлом будет немного универсальнее — кто знает, как много данных нужно записать? А вдруг память закончится?
Тем более, можно использовать что-то вроде:
Относительно кратко и делает ту же работу.
Тем более, можно использовать что-то вроде:
grep '^Success:\s ' < messages.log > messages.log_ ; mv messages.log{_,}
Относительно кратко и делает ту же работу.
Если нужно обработать много данных — то да, решение с временным файлом безусловно безопаснее.
Но лично я бы, если бы мне нужно было делать такое часто, устал каждый раз набирать такую длинную конструкцию. Как вариант, кстати, нам же никто не мешает дописать себе в ~/.bashrc (~/.bash_profile) что-нибудь такое (wf в смысле «write file»):
А потом, соответственно, можно просто писать:
Но лично я бы, если бы мне нужно было делать такое часто, устал каждый раз набирать такую длинную конструкцию. Как вариант, кстати, нам же никто не мешает дописать себе в ~/.bashrc (~/.bash_profile) что-нибудь такое (wf в смысле «write file»):
function wf() {
local tmpfile="$@_$(< /dev/urandom tr -dc A-Za-z0-9 | head -c16)"
cat > $tmpfile
mv $tmpfile "$@"
}
А потом, соответственно, можно просто писать:
grep "^Success:\s" messages.log | wf messages.log
А ещё специально для вас есть mktemp
mktemp создаёт файлы в /tmp, и если последний смонтирован на другом разделе, то mv не просто переименует файл, а будет переносить его на другой раздел. В этом плане создание временного файла в той же директории для подобных задач корректнее использования mktemp.
Это не просто будет работать быстрее, при этом ещё и гарантируется, что итоговый файл будет полностью обработан или не обработан вообще (переименование — атомарная операция).
Это не просто будет работать быстрее, при этом ещё и гарантируется, что итоговый файл будет полностью обработан или не обработан вообще (переименование — атомарная операция).
И вот, значит, есть у нас SQL дамп на 100 гигабайт…
>Это достаточно детально описано в главе I/O Redirection в «Продвинутом руководстве по программированию на Bash» (Advanced Bash-Scripting Guide).
Этот гайд есть частично переведенный на русский, если кому надо: www.bash-scripting.ru/abs/chunks/
Этот гайд есть частично переведенный на русский, если кому надо: www.bash-scripting.ru/abs/chunks/
А рассматриваемый в данной статье пример достаточно подробно разобран в книге Unix. Программное окружение.
Только вот забыли добавить, что это тулза не идет в поставке стандартно почти ни с каким *nix… В отличии от sed того же, который есть почти везде сразу.
По-моему это очевидно из:
>это программа sponge из moreutils
Много чего не идет в стандартной поставке… И что мешает ее установить?
>это программа sponge из moreutils
Много чего не идет в стандартной поставке… И что мешает ее установить?
То, что это не является зачаствую разумным или возможным (ставить доп. ПО), или по умолчанию считается что все везде админы?
Намного проще и лучше использовать универсальный функционал, а не ставить утилиты на любой чих.
Это совет сродни «Чтобы машина держала скорость, надо включить круиз контроль. Нету? Поставьте дополнительно!»
Sed в данном случае — стандарт практически.
Намного проще и лучше использовать универсальный функционал, а не ставить утилиты на любой чих.
Это совет сродни «Чтобы машина держала скорость, надо включить круиз контроль. Нету? Поставьте дополнительно!»
Sed в данном случае — стандарт практически.
> или по умолчанию считается что все везде админы?
Ну, если человек не может установить дополнительную утилиту, то и sponge вряд ли ему нужна…
> Намного проще и лучше использовать универсальный функционал, а не ставить утилиты на любой чих.
В том-то и суть unix way: кому-то нужен один функционал, кому-то другой, для этого и существуют репозитории с возможностью доустановить то, что необходимо, а если пытаться создать универсальный дистрибутив на все случаи жизни, то его не то, что выкачивать замучаешься, но и разворачивать/настраивать/обновлять, не говоря уже о том, что большая часть функционала будет мертвым грузом…
Ну, если человек не может установить дополнительную утилиту, то и sponge вряд ли ему нужна…
> Намного проще и лучше использовать универсальный функционал, а не ставить утилиты на любой чих.
В том-то и суть unix way: кому-то нужен один функционал, кому-то другой, для этого и существуют репозитории с возможностью доустановить то, что необходимо, а если пытаться создать универсальный дистрибутив на все случаи жизни, то его не то, что выкачивать замучаешься, но и разворачивать/настраивать/обновлять, не говоря уже о том, что большая часть функционала будет мертвым грузом…
Какой-то дет. сад, ей богу.
У кучи разработчиков (да у 99%) например нет административных доступов на сервера с которыми они работают. Мало того, если такой горе-разработчик напишет скрипты которые используют «левую» утилиту — то получит по ушам.
Есть базовый, устоявшийся набор утилит который присутствует практически в любом *nix. Ставить дополнительное ПО для того, чтобы работать с буфером файлов — это мягко говоря странно, ладно бы речь шла о чем-то сложном.
То что вы описываете — это не unix-way, это как раз самый что ни на есть windows way — на любой чих ставить утилитку.
У кучи разработчиков (да у 99%) например нет административных доступов на сервера с которыми они работают. Мало того, если такой горе-разработчик напишет скрипты которые используют «левую» утилиту — то получит по ушам.
Есть базовый, устоявшийся набор утилит который присутствует практически в любом *nix. Ставить дополнительное ПО для того, чтобы работать с буфером файлов — это мягко говоря странно, ладно бы речь шла о чем-то сложном.
То что вы описываете — это не unix-way, это как раз самый что ни на есть windows way — на любой чих ставить утилитку.
Сочувствую вашим разработчикам…
Сочувствуйте лучше себе :)
Вы похоже на самом деле не понимаете что такое стандарты, почему их надо придерживаться, зачем нужно делать портабельный софт и скрипты, почему не надо городить дополнительные зависимости на пустом месте (как библиотеки, так и «утилитки»), и тд.
Скорее всего это придет позже, после того как начнете заниматься действительно серьезными проектами. Если начнёте.
Вы похоже на самом деле не понимаете что такое стандарты, почему их надо придерживаться, зачем нужно делать портабельный софт и скрипты, почему не надо городить дополнительные зависимости на пустом месте (как библиотеки, так и «утилитки»), и тд.
Скорее всего это придет позже, после того как начнете заниматься действительно серьезными проектами. Если начнёте.
Это не тот случай. Это как раз unix-way.
Windows-way был бы, если бы пришлось ставить какую-то программу, которая выполняет какую-то прикладную задачу (при этом не расширяется, не автоматизируется, выполняет её плохо или выполняет только некоторый сценарий задачи), вместо написания bash файла из 3-х строчек.
Пакет «moreutils» доступен, наверное, в каждом дистрибьютиве. Входит в пакетную базу дистрибьютива. Это не то же самое что ставить 3rd party программу неизвестно откуда. И то что выполняет sponge — универсальная задача, подходит для скриптинга.
Ставить новый пакет или нет ради этого — это дело хозяйское, в разных ситуациях может быть по разному.
Использовать вместо sponge свой велосипед или хак с временными файлами — это как раз не unix-way (если использовать часто, и если нет требований по памяти, простоте деплоя)
Откуда такая статистика? Помоему с потолка. Откуда вообще информация что у большинства разработчиков нет прав? Помоему тоже с потолка.
Windows-way был бы, если бы пришлось ставить какую-то программу, которая выполняет какую-то прикладную задачу (при этом не расширяется, не автоматизируется, выполняет её плохо или выполняет только некоторый сценарий задачи), вместо написания bash файла из 3-х строчек.
Пакет «moreutils» доступен, наверное, в каждом дистрибьютиве. Входит в пакетную базу дистрибьютива. Это не то же самое что ставить 3rd party программу неизвестно откуда. И то что выполняет sponge — универсальная задача, подходит для скриптинга.
Ставить новый пакет или нет ради этого — это дело хозяйское, в разных ситуациях может быть по разному.
Использовать вместо sponge свой велосипед или хак с временными файлами — это как раз не unix-way (если использовать часто, и если нет требований по памяти, простоте деплоя)
У кучи разработчиков (да у 99%)
Откуда такая статистика? Помоему с потолка. Откуда вообще информация что у большинства разработчиков нет прав? Помоему тоже с потолка.
Ну вот у меня на работе например так. На дев сервере у меня нет прав на это. И это правильно. Я вообще программист клиент сайда. А ещё есть 100500 боевых серверов, я даже не знаю их количество. Ладно, на дев можно попросить админов поставить, но на бой то зачем тащить? На все сразу сервера. А если в скрипте заюзаю. В общем за статью спасибо большое, новое узнал. А этот спор он ни к чему.
Спасибо, не знал про такую удобную штуку.
Даёшь больше обзоров хороших shell утилит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Команда sponge: «губка» для стандартного ввода