LINUX.ORG.RU

cat list | xargs du

aol ★★★★★
()
Ответ на: комментарий от aol

упс. Ну ладно, поторопился. Без аргумента работает

minakov ★★★★★
()
Ответ на: комментарий от drBatty

1. котэ няшные?

Смотря какие, моя кошка очень.

2. du считает не размер, а занимаемое место.

Значит заменить на тот же stat... или слишком сложно для местного населения?

do echo -n "$file: ";stat --format=%s "$file";done

erfea ★★★★★
()
Последнее исправление: erfea (всего исправлений: 1)
Ответ на: комментарий от drBatty

Соль не в кошках. Жестоко читать весь файл для определения его размера.

Lavos ★★★★★
()
Ответ на: комментарий от lllnk

Одна кошка лишняя,

вторая тоже. а читать все байты попросту глупо.

drBatty ★★
()
Ответ на: комментарий от erfea

Да чем тебе это няшное животное не угодило? Воспитанная кошка, по углам не ссыт...

в одностроке оно только тупит и тормозит. лишняя сущность, которая часто приводит к проблемам. вот одна из них:

cat file | sed '...' #тут файл обрабатывается sed фильтром

cat file | sed '...' >tmp && rm file && mv tmp file # а тут мы поменяли содержимое файла в соответствии с фильтром

sed -i '...' file # тоже самое, только без кошек и временных мисок, куда им надо срать.

drBatty ★★
()
Ответ на: комментарий от drBatty

Я, конечно, понимаю... кошки тебе как-то насрали на столе рабочем. Но сравнение имхо не очень то корректное ты привёл. В твоём случае кошка реально не уместна. Однако то что я сделал с неё вполне работоспособно и проблем за собой не влечет, не придумавый их там где нету.

erfea ★★★★★
()
Ответ на: комментарий от erfea

Я, конечно, понимаю... кошки тебе как-то насрали на столе рабочем. Но сравнение имхо не очень то корректное ты привёл. В твоём случае кошка реально не уместна.

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 умеет это всё делать без всяких кошек.

drBatty ★★
()
Ответ на: комментарий от drBatty

Ты упоротый?! Где ты увидел в моем одностроке «rm && mv для создания временного файла»?! Без чудиков знаю что такое sed -i. Но где ты там вообще sed увидел, что им делать?! Дрочить на него?! Кошка была заюзана чтоб создать поток, while read прекрасно разбирает его на строки. Это просто, очевидно, наглядно и работает. Без каких либо проблем. Что ты мне тут придумываешь?! Тебя так обидело что конструкция cat file| sed -e '***' > file не работоспособна! Но я это и без тебя знаю и она тут не причём, это просто твои комплексы...

erfea ★★★★★
()
Ответ на: комментарий от erfea

успокойся-ты... кошку свою погладь...

Погладил? Хорошо. Я писал про одну из проблем. 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) с созданием отдельного процесса. Во первых это довольно доооолгоооо, во вторых это отдельный контекст, что тупо неудобно (сувать туда неудобно, а извлекать оттуда так вообще через ж).

ЗЫЖ довольно грустно смотреть не быдлокодеров, которые сначала напишут быдлокод, а потом ругают язык, на котором они быдлокодят(криво и медленно!)... Какой ЯП - нет никакой разницы.

drBatty ★★
()
Ответ на: комментарий от drBatty

# внутри цикла не работают переменные

Да вы, батенька, Америку открыли!

Во первых это довольно доооолгоооо

Ага, на том тривиальном примере критично... Надо было писать на асме иновационную нанопрограммку вместо тупого однострока :D

Ты опять приводишь тупые примеры... Ссылаешься на не критичные недостатки. Давай всё же по контексту поставленной задачи, чем моё решение в лоб плохо?! Отдельные случаи (работа с переменными, требуется производительность и т.д.) будем рассматривать в другом треде. Если у меня идёт более или менее нагруженный скрипт, применяются другие решения. А когда я тупо смотрю в консоль и мне нужно что-то сделать, я выбираю что-то что выполнит задачу в лоб, оптимизировать эту строчку нету смысла.

erfea ★★★★★
()
Ответ на: комментарий от drBatty

PS: откуда такой идиотский вопрос?

Да так, прошёлся по своей 2 террабайтной файлопомойке fdupes'ом, а теперь пытаюсь понять, что бы какого удалить

mm3 ★★★
() автор топика
Ответ на: комментарий от drBatty

Ты не прав. Здесь не production ready код, а учебный, который как правило создают пошагово

посмотреть на структуру файла
$ cat file.txt

выделить какие-то строки
жмем стрелку вверх (предыд. команду)
$ cat file.txt | grep sometext

потом добавляем awk, 
$ cat file.txt | grep sometext | awk ... 
и т.д.
И только в конце убираем все лишне

но здесь на ЛОРе еще и однострочники оптимизировать, делать больше нечего что-ли?

sdio ★★★★★
()
Ответ на: комментарий от drBatty

sed тут действительно не причём, при чём - дурацкая привычка ставить cat где надо и где не надо. В частности перед командой типа sed.

а если рассмотреть этот вопрос с другой стороны? если источник данных может смениться? или к примеру появится необходимость дополнительно обработать поток перед выполнением протестированного действия? то уже дурацкой привычкой видится пихание везде где нужно и ненужно «оптимизированного» чтения через флаги типа -i, а такде всякие -e -f -file и прочие так как у каждой команды свой флаг...

mm3 ★★★
() автор топика
Ответ на: комментарий от erfea

Ты опять приводишь тупые примеры... Ссылаешься на не критичные недостатки. Давай всё же по контексту поставленной задачи, чем моё решение в лоб плохо?!

знаешь, если-бы я хотел сказать «убивать таких надо!!!111», то так и сказал-бы. Я такого НЕ ГОВОРИЛ. Вряд-ли ты умрёшь ковыряя в носу, но это не говорит о том, что ковырять в носу - хорошо (: Просто вредная привычка.

Надо было писать на асме

ЯП тут не причём, см. выше.

оптимизировать эту строчку нету смысла.

есть только ОДИН случай, когда допустимо писать не оптимальный код - когда это повышает наглядность

ОСОБЕННО в примерах для начинающих. Вот ты знаешь про переменные и ключи sed? Знаешь. А вот ТС - вряд-ли. Ну и зачем его расстраивать потенциально ошибочным кодом? Зачем лишняя сущность, которая здесь НЕ НУЖНА? В мире полно интересного, чего ТС сейчас не волнует, в т.ч. и в баше.

drBatty ★★
()
Ответ на: комментарий от mm3

Да так, прошёлся по своей 2 террабайтной файлопомойке fdupes'ом, а теперь пытаюсь понять, что бы какого удалить

вы-бы лучше find освоили - она не только по имени умеет, но и ещё по разному. Удалять, кстати, тоже умеет, и по размеру - тоже. Размер тоже может нарисовать...

drBatty ★★
()
Ответ на: комментарий от sdio

Ты не прав. Здесь не production ready код, а учебный, который как правило создают пошагово

один ламер методом тыка набыдлокодил быдлоскрипт и спрашивает

мужики, что-то у мну вот эта строчка не работает echo «test... test... test...» | perl -e и так далее

это уже было в симпсонах (:

но здесь на ЛОРе еще и однострочники оптимизировать, делать больше нечего что-ли?

ты помочь хочешь? ну дык помоги.

drBatty ★★
()
Ответ на: комментарий от mm3

а если рассмотреть этот вопрос с другой стороны? если источник данных может смениться?

дык и я про то. Здесь у нас всё - файлы, потому источником и должны быть ФАЙЛЫ. А не stdin (это тоже файл, но совсем не простой, и многие команды с ним работают по другому. Иногда НЕОЖИДАННО).

или к примеру появится необходимость дополнительно обработать поток перед выполнением протестированного действия?

кто тебе сказал, что это ПОТОК? Это ФАЙЛ(Ы). не обязательно поток.

то уже дурацкой привычкой видится пихание везде где нужно и ненужно «оптимизированного» чтения через флаги типа -i, а такде всякие -e -f -file и прочие так как у каждой команды свой флаг...

«свой флаг» разве что у xargs, т.к. это наверное единственная команда для работы с ПОТОКОМ (она и разворачивает поток в список имён файлов). Остальные команды работают со списком файлов, а ключи нужны для другого. Например sed -i не только принимает файлы, но ещё и заворачивает результат обработки каждого файла сам в себя. Та же cat на самом деле нужна для разворачивания нескольких файлов в один поток. А вовсе не для такого черезжопного использования.

Т.ч. каких-то особых флагов зубрить не нужно.

drBatty ★★
()
Ответ на: комментарий от sdio

Ну ладно, давай, приходи в каждую тему и бубни о лишних кошках.

ну спасибо за разрешение. Захочу третью звезду - вспомню твой совет (:

drBatty ★★
()
Ответ на: комментарий от drBatty

sed -i не только принимает файлы, но ещё и заворачивает результат обработки каждого файла сам в себя.

Как это? Он же создает временный файл типа sed > tmp && mv tmp out

sdio ★★★★★
()
Ответ на: комментарий от drBatty

кто тебе сказал, что это ПОТОК? Это ФАЙЛ(Ы). не обязательно поток.

вообще то пайпы это далеко не файлы, хоть и позволяют с собой работать практически как с обычными файлами, отсюда и выходит что со stdin'ом некоторые команды работают неожиданно. А не именованные пайпы так вообще не имеют своего представления на файловой системе.

И через пайпы таки идёт поток данных, который может быть как сгенерирован так и обработан в потоковом режиме. Не зря же sed является потоковым редактором.

mm3 ★★★
() автор топика
Ответ на: комментарий от sdio

Как это? Он же создает временный файл типа sed > tmp && mv tmp out

угу. грубо говоря так оно и есть. но называется это «редактирование на месте»

drBatty ★★
()
Ответ на: комментарий от mm3

вообще то пайпы это далеко не файлы, хоть и позволяют с собой работать практически как с обычными файлами, отсюда и выходит что со stdin'ом некоторые команды работают неожиданно.

вообще-то пайпы это файлы. Это частный случай файлов. А неожиданности от того, что в коде утилит проверка имеется, регулярный это файл, или нет.

А не именованные пайпы так вообще не имеют своего представления на файловой системе.

ну и что? это не единственные файлы, у которых ноль имён. У файла может быть любое количество имён, ноль в том числе.

И через пайпы таки идёт поток данных, который может быть как сгенерирован так и обработан в потоковом режиме. Не зря же sed является потоковым редактором.

как не странно, но sed называют «потоковым» совсем не из-за работы именно с потоками. Sed работает с файлами как с потоком(и). Работа именно с stdin это просто частный случай. Точно также, как и для большинства утилит(в т.ч. и cat).

drBatty ★★
()
Ответ на: комментарий от sdio

звучит по-ламерски

нормально для тех, кто не осилил это:

`-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.

drBatty ★★
()
Ответ на: комментарий от drBatty

я что-то не уловил? мне кажется, что обсуждение sed в этом топике совсем не в тему..

qnikst ★★★★★
()
Ответ на: комментарий от sdio

И где здесь «заворачивает результат обработки каждого файла сам в себя»?

я согласен, что

обсуждение sed в этом топике совсем не в тему..

если ты хочешь поговорить об этом, или ты нираспарсил цитаты, открывай другой топик.

drBatty ★★
()
Ответ на: комментарий от drBatty

Лекции о лишних cat здесь тоже не в тему, но ведь кто-то любит потрясти своим ЧСВ.

sdio ★★★★★
()
Ответ на: комментарий от Nicholass

Дурацкий вариант от меня

вот ещё find -printf «%s\n»

drBatty ★★
()
Ответ на: комментарий от mm3

эх... ещё бы он умел удалять дубликаты директорий, цены бы ему не было

удали дубликаты файлов, а потом пустые директории find -type d -empty -delete как-то так.

drBatty ★★
()
Ответ на: комментарий от mm3

Что такое «дубликаты директорий» (я серьезно)? Если это директории, содержащие одинаковые файлы и не содержащие неодинаковые, то после удаления файлов-дубликатов все дубликаты директорий, кроме одной, станут пустыми. Задача сведется к поиску и удалению пустых каталогов, разрешимую тривиальным find -depth -type d -empty -delete

dexpl ★★★★★
()
Последнее исправление: dexpl (всего исправлений: 1)
Ответ на: комментарий от dexpl

представь ситуацию есть кучка одинаковых файлов, чаще всего текстовых и не очень больших, которые встречается в куче разных мест и в некоторых местах они нужны, а в некоторых они лежат в дубликатах директорий, и быстрым взглядом на список из 20 мест расположения одинаковых файлов трудно определить где это дубликаты, а где нужные копии, но если бы была возможность определить, что директории /a/b/a/a/ и /a/c/d/a/a/f/a/ именют одинаковое содержимое и одну из них можно почистить то это резко упростило бы задачу.

mm3 ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.