Я, конечно, понимаю... кошки тебе как-то насрали на столе рабочем. Но сравнение имхо не очень то корректное ты привёл. В твоём случае кошка реально не уместна. Однако то что я сделал с неё вполне работоспособно и проблем за собой не влечет, не придумавый их там где нету.
Я, конечно, понимаю... кошки тебе как-то насрали на столе рабочем. Но сравнение имхо не очень то корректное ты привёл. В твоём случае кошка реально не уместна.
cat ВСЕГДА не уместна.
Однако то что я сделал с неё вполне работоспособно и проблем за собой не влечет, не придумавый их там где нету.
вот ты не поверишь, но sed -i делает тоже самое. Это ещё что, sed -i '...' *.c примерно эквивалентно
for F in *.c
do
TMP=`mktemp`
cat $F | sed '...' >$TMP || exit
rm $F || exit
mv $TMP $F || exit
done
И кстати в этом коде cat тоже не уместна, я просто показываю, к чему это приводит. Причина в том, что stdin неразрывный и безымянный, потому и приходится наворачивать цикл, для того, что-бы порвать поток, и ещё rm && mv для создания временного файла. Это конечно круто, но sed умеет это всё делать без всяких кошек.
Ты упоротый?! Где ты увидел в моем одностроке «rm && mv для создания временного файла»?! Без чудиков знаю что такое sed -i. Но где ты там вообще sed увидел, что им делать?! Дрочить на него?! Кошка была заюзана чтоб создать поток, while read прекрасно разбирает его на строки. Это просто, очевидно, наглядно и работает. Без каких либо проблем. Что ты мне тут придумываешь?! Тебя так обидело что конструкция cat file| sed -e '***' > file не работоспособна! Но я это и без тебя знаю и она тут не причём, это просто твои комплексы...
Погладил? Хорошо. Я писал про одну из проблем. sed тут действительно не причём, при чём - дурацкая привычка ставить cat где надо и где не надо. В частности перед командой типа sed. Команды написаны не дебилами, во всяком случае не глупее тех, кто cat писал, и эти команды сами могут жрать файл(ы), а не подъедать высер cat.
В твоём коде другая проблема:
$ X=17; cat f|while read Y; do X=33; done; echo $X
17 # внутри цикла не работают переменные
$ X=17; while read Y; do X=33; done <f; echo $X
33 # а без cat таки работают
$ export X=17; cat f|while read Y; do X=33; done; echo $X
17 # так они входят в субшелл, но из него не выходят.
Как видишь, pipe приводит к fork(2) с созданием отдельного процесса. Во первых это довольно доооолгоооо, во вторых это отдельный контекст, что тупо неудобно (сувать туда неудобно, а извлекать оттуда так вообще через ж).
ЗЫЖ довольно грустно смотреть не быдлокодеров, которые сначала напишут быдлокод, а потом ругают язык, на котором они быдлокодят(криво и медленно!)... Какой ЯП - нет никакой разницы.
Ага, на том тривиальном примере критично... Надо было писать на асме иновационную нанопрограммку вместо тупого однострока :D
Ты опять приводишь тупые примеры... Ссылаешься на не критичные недостатки. Давай всё же по контексту поставленной задачи, чем моё решение в лоб плохо?! Отдельные случаи (работа с переменными, требуется производительность и т.д.) будем рассматривать в другом треде. Если у меня идёт более или менее нагруженный скрипт, применяются другие решения. А когда я тупо смотрю в консоль и мне нужно что-то сделать, я выбираю что-то что выполнит задачу в лоб, оптимизировать эту строчку нету смысла.
Ты не прав. Здесь не production ready код, а учебный, который как правило создают пошагово
посмотреть на структуру файла
$ cat file.txt
выделить какие-то строки
жмем стрелку вверх (предыд. команду)
$ cat file.txt | grep sometext
потом добавляем awk,
$ cat file.txt | grep sometext | awk ...
и т.д.
И только в конце убираем все лишне
но здесь на ЛОРе еще и однострочники оптимизировать, делать больше нечего что-ли?
sed тут действительно не причём, при чём - дурацкая привычка ставить cat где надо и где не надо. В частности перед командой типа sed.
а если рассмотреть этот вопрос с другой стороны? если источник данных может смениться? или к примеру появится необходимость дополнительно обработать поток перед выполнением протестированного действия? то уже дурацкой привычкой видится пихание везде где нужно и ненужно «оптимизированного» чтения через флаги типа -i, а такде всякие -e -f -file и прочие так как у каждой команды свой флаг...
Ты опять приводишь тупые примеры... Ссылаешься на не критичные недостатки. Давай всё же по контексту поставленной задачи, чем моё решение в лоб плохо?!
знаешь, если-бы я хотел сказать «убивать таких надо!!!111», то так и сказал-бы. Я такого НЕ ГОВОРИЛ. Вряд-ли ты умрёшь ковыряя в носу, но это не говорит о том, что ковырять в носу - хорошо (: Просто вредная привычка.
Надо было писать на асме
ЯП тут не причём, см. выше.
оптимизировать эту строчку нету смысла.
есть только ОДИН случай, когда допустимо писать не оптимальный код - когда это повышает наглядность
ОСОБЕННО в примерах для начинающих. Вот ты знаешь про переменные и ключи sed? Знаешь. А вот ТС - вряд-ли. Ну и зачем его расстраивать потенциально ошибочным кодом? Зачем лишняя сущность, которая здесь НЕ НУЖНА? В мире полно интересного, чего ТС сейчас не волнует, в т.ч. и в баше.
Да так, прошёлся по своей 2 террабайтной файлопомойке fdupes'ом, а теперь пытаюсь понять, что бы какого удалить
вы-бы лучше find освоили - она не только по имени умеет, но и ещё по разному. Удалять, кстати, тоже умеет, и по размеру - тоже. Размер тоже может нарисовать...
а если рассмотреть этот вопрос с другой стороны? если источник данных может смениться?
дык и я про то. Здесь у нас всё - файлы, потому источником и должны быть ФАЙЛЫ. А не stdin (это тоже файл, но совсем не простой, и многие команды с ним работают по другому. Иногда НЕОЖИДАННО).
или к примеру появится необходимость дополнительно обработать поток перед выполнением протестированного действия?
кто тебе сказал, что это ПОТОК? Это ФАЙЛ(Ы). не обязательно поток.
то уже дурацкой привычкой видится пихание везде где нужно и ненужно «оптимизированного» чтения через флаги типа -i, а такде всякие -e -f -file и прочие так как у каждой команды свой флаг...
«свой флаг» разве что у xargs, т.к. это наверное единственная команда для работы с ПОТОКОМ (она и разворачивает поток в список имён файлов). Остальные команды работают со списком файлов, а ключи нужны для другого. Например sed -i не только принимает файлы, но ещё и заворачивает результат обработки каждого файла сам в себя. Та же cat на самом деле нужна для разворачивания нескольких файлов в один поток. А вовсе не для такого черезжопного использования.
кто тебе сказал, что это ПОТОК? Это ФАЙЛ(Ы). не обязательно поток.
вообще то пайпы это далеко не файлы, хоть и позволяют с собой работать практически как с обычными файлами, отсюда и выходит что со stdin'ом некоторые команды работают неожиданно. А не именованные пайпы так вообще не имеют своего представления на файловой системе.
И через пайпы таки идёт поток данных, который может быть как сгенерирован так и обработан в потоковом режиме. Не зря же sed является потоковым редактором.
вообще то пайпы это далеко не файлы, хоть и позволяют с собой работать практически как с обычными файлами, отсюда и выходит что со stdin'ом некоторые команды работают неожиданно.
вообще-то пайпы это файлы. Это частный случай файлов. А неожиданности от того, что в коде утилит проверка имеется, регулярный это файл, или нет.
А не именованные пайпы так вообще не имеют своего представления на файловой системе.
ну и что? это не единственные файлы, у которых ноль имён. У файла может быть любое количество имён, ноль в том числе.
И через пайпы таки идёт поток данных, который может быть как сгенерирован так и обработан в потоковом режиме. Не зря же sed является потоковым редактором.
как не странно, но sed называют «потоковым» совсем не из-за работы именно с потоками. Sed работает с файлами как с потоком(и). Работа именно с stdin это просто частный случай. Точно также, как и для большинства утилит(в т.ч. и cat).
`-i[SUFFIX]'
`--in-place[=SUFFIX]'
This option specifies that files are to be edited in-place. GNU
`sed' does this by creating a temporary file and sending output to
this file rather than to the standard output.(1).
This option implies `-s'.
When the end of the file is reached, the temporary file is renamed
to the output file's original name. The extension, if supplied,
is used to modify the name of the old file before renaming the
temporary file, thereby making a backup copy(2)).
This rule is followed: if the extension doesn't contain a `*',
then it is appended to the end of the current filename as a
suffix; if the extension does contain one or more `*' characters,
then _each_ asterisk is replaced with the current filename. This
allows you to add a prefix to the backup file, instead of (or in
addition to) a suffix, or even to place backup copies of the
original files into another directory (provided the directory
already exists).
If no extension is supplied, the original file is overwritten
without making a backup.
Что такое «дубликаты директорий» (я серьезно)? Если это директории, содержащие одинаковые файлы и не содержащие неодинаковые, то после удаления файлов-дубликатов все дубликаты директорий, кроме одной, станут пустыми. Задача сведется к поиску и удалению пустых каталогов, разрешимую тривиальным find -depth -type d -empty -delete
представь ситуацию есть кучка одинаковых файлов, чаще всего текстовых и не очень больших, которые встречается в куче разных мест и в некоторых местах они нужны, а в некоторых они лежат в дубликатах директорий, и быстрым взглядом на список из 20 мест расположения одинаковых файлов трудно определить где это дубликаты, а где нужные копии, но если бы была возможность определить, что директории /a/b/a/a/ и /a/c/d/a/a/f/a/ именют одинаковое содержимое и одну из них можно почистить то это резко упростило бы задачу.