как однострочником узнать размеры файлов заданных списком?

ls -l < files.txt

cat list | xargs du

ты хоть попробовал перед тем, как советовать?!

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

Ещё wc может считать байты

Ещё wc может считать байты

cat filelist | xargs cat | wc --bytes ? Жестоко.

stat скажет размер файла, не читая его

xargs --arg-file=list stat --format=%s

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

cat filelist | xargs cat | wc --bytes ? Жестоко.

две ненужные кошки? не нужно.

cat files|while read file;do du -h "$file";done

проще пареной репы

проще пареной репы

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

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

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

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

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

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

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

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

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

cat filelist | xargs wc --bytes

Я слоупок :(

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

ну это всё равно не повод пихать её в однострок.

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

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

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

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

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

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

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

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

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

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

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

Ты упоротый?! Где ты увидел в моем одностроке «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

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

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

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

Ты не прав. Здесь не 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 освоили - она не только по имени умеет, но и ещё по разному. Удалять, кстати, тоже умеет, и по размеру - тоже. Размер тоже может нарисовать...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вообще то пайпы это далеко не файлы, хоть и позволяют с собой работать практически как с обычными файлами, отсюда и выходит что со 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.

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

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

ЕМНИП, fdupes умеет удалять дубликаты

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

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

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

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

ls -lah | awk '{print $5}'

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

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

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

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

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

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

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

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

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