Как сделать cat file | grep text > file?

Собственно, все решения, предложенные в треде - обоснование убедительнее некуда.

Не могу согласиться.

Бóльшая их часть ТСу вообще непригодны, ибо не позволяют использовать паровоз из нескольких грепов.

Да ну? Можете перечислить, какие именно?

Ну и вообще говоря, трубопровод из нескольких грепов — это, скорее всего, дурноватое решение.

Эскейпить затрахаешься.

ORLY? Что, например, я выше недоэкранировал?

То, что там два махровых башизма и нет комментария, что порядок перенаправлений существенен, это ерунда, решение на самом деле изящное.
А вот интереснее то, что все, предлагавшие воспользоваться подстановкой команды, привели примеры попросту некорректные.
Во-первых, она (строго по POSIX!) cъедает все хвостовые \n. При записи в переменную это можно обойти в любом хоть-сколько-нибудь POSIX-совместимом шелле, хотя при этом ясность и лаконизм куда-то уходят.
Во-вторых, съедаются все \000, и это принципиально неисправимо. Для TS это наверняка не важно (как, может быть, и во-первых), но осадочек-то остаётся.

Кстати, mktemp(1) (не путать с исключённым из POSIX mktemp(3)!) хоть в POSIX ещё не попал, но довольно давно уже живёт в coreutils и busybox, и поэтому достаточно безопасен/надёжен.

Во-вторых, съедаются все \000, и это принципиально неисправимо

Да, когда речь о всяких grep’ах, данные по-умолчанию считаются строго текстовыми. Это само собой разумеющееся.

cъедает все хвостовые \n

Хм...

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

Благодарю за повод к размышлению.

при этом ясность и лаконизм куда-то уходят

Странно, а у меня не уходят.

$ buf=$(grep 'regex' "$file")
$ printf '%s\n' "$buf" > "$file"

Но что́ у вас за поставка такая, что спросить на ЛОРе проще, чем у нее самой, хотелось бы знать.

А что такое «поставка»? Дистрибутив? Тогда Gentoo. Не даёт информацию о входящих в пакет файлах, пока пакет не установишь.

P.S. А moreutils к Гну не относится. Совершенно независимые утилиты.

Странно, а у меня не уходят.

Потому что это не решение.
Чтобы отдать ровно столько хвостовых \n, сколько их было, надо

  buf="$( grep 'regex' "$file" ; echo / )"
  printf '%s' "${buf%/}" > "$file"

Но что́ у вас за поставка такая, что спросить на ЛОРе проще, чем у нее самой, хотелось бы знать.

А что такое «поставка»? Дистрибутив? Тогда Gentoo.

Да. Хотя меня куда больше интересует, что такое «дистрибутив». Вернее каким макаром это английское *прилагательное* стало значить поставку при том, что в английском оно этого значения не имеет.

Не даёт информацию о входящих в пакет файлах, пока пакет не установишь.

Безобразие.

А moreutils к Гну не относится.

Я в курсе.

Потому что это не решение.

Почему же?

Чтобы отдать ровно столько хвостовых \n, сколько их было, надо...

Зачем? Не вы ли тут только что козыряли знанием всякой бюрократии?

но в общем случае всё гораздо хуже

Общих случаев не бывает. Всегда существуют пределы применимости.

Кроме moreutils еще есть какие-нибудь такие пакеты?

Ну, firefox-esr, например, есть.

Нет, ну все-таки, что вы имели в виду? Где еще можно взять sponge, кроме как в этих moreutils?

Ну можно самому написать. Кажется, например, вот такой он может быть, если для текстовых файлов:

#!/bin/sed -znf

p

Впрочем, не проверял.

Нет, ну все-таки, что вы имели в виду?

Ну, в смысле еще куча каких-нибудь таких утилит для работы с потоками.

А чтобы не потерять код возврата, для grep достаточно замены ';' на '&&', но в общем случае всё гораздо хуже

Всё это, конечно, увлекательно, но алгоритм у «sed -n '/text/p' -i file» наверное не просто так придуман? Вот у вас, скажем, первая ваша команда всосёт результат grep-а, гиг так несколько, а пока вторая команда будет готовиться его записать, вдруг окажется, что oomkiler таки решит убить ваш разожравшийся bash, и вы окажетесь без результата и исходных данных.

Да. Хотя меня куда больше интересует, что такое «дистрибутив». Вернее каким макаром это английское *прилагательное* стало значить поставку при том, что в английском оно этого значения не имеет.

Слово «поставка» слишком многозначное, и вместо «дистрибутива» его пока используешь один ты. (Или уже разослал российским дистрибутивам и переводчикам иностранных требования писать и говорить правильно?) Грамматически правильное «дистрибуция» на 1 слог длиннее.

Не думается, что причина в этом. Язык так не работает.

А я здесь при чём? Я просто пытался обратить внимание некоторых на некорректность их решений. Но, похоже, зря метал бисер.

А я здесь при чём?

Ну как же. Вы ударились в мелочные воздуси, как-будто только в них и были основные проблемы.

Я просто пытался обратить внимание некоторых на некорректность их решений.

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

Но, похоже, зря метал бисер.

Возможно. Ибо на bash то оконечные пустые строки не проблема для загрузки в переменную. Ну, скажем так:

#!/bin/bash

IFS= read -r -d '' buf < <(grep text file; echo )
echo -n "$buf"

Язык так не работает.

Напряг память и вспомнил, что было 20-25 лет назад. «Distributuion package» в официозных текстах переводили как «дистрибутивный пакет» вместо более правильного «дистрибуционный пакет». А в разговорной речи сокращали до «дистрибутив». Всё под ДОС, потому что Виндоуз был «сакс», а про другие даже не слышали.

юзай после grep утилиту sponge из sys-apps/moreutils

Вот это уже куда больше похоже на истинную теорию. Большое спасибо.