wc -l

хотя в обоих случаях файлы, в названии которых есть '\n' обработаются неправильно.

в общем нужно найденные файлы перенаправить в файл, а общее количество вывести на консоль

В файл нужно передать имена найденных файлов или их содержимое? Если имена, то

find /usr/share -type f -a -size +4000c -a -size -4002c > found.txt
wc -l found.txt

в названии которых есть '\n' обработаются неправильно

можно так: find ... -printf 'ы' | wc -m

ну '\n' в названиях файлов это нонсенс, так что не беда, беда в другом, мне на каждый найденный файл нужно сделать несколько вещей: напечатать в отдельной строке 1) размер в байтах, 2) путь до файла без имени файла, 3) имя файла без пути и напечатать это надо не в stdout,а в другой файл, а счетчик вывести в stdout, так что wc -l не покатит.

так более или менее, только у меня на каждый файл получится по 4 строчки, но это не беда.

как вы задолбали конвейеры строить.

C=0
while read
do (( C++ ))
done< <(find)

1) размер в байтах, 2) путь до файла без имени файла, 3) имя файла без пути

find ... -printf '%s\t%h\t%f\n' >output.txt && wc -l output.txt

цикл выполняется в саб шелле?

Не совсем, но у тебя в строчке есть конвеер/пайпа <|> а это в свою очередь форкает твой скрипт, тоесть то что слева от | это один процесс, то что справа - другой. Убери пайпу и замени while read на простой foreach, както так:

#!/bin/bash

OIFS="${IFS}"
NIFS="
"
IFS="${NIFS}"
files=`find /usr/share -type f -a -size +4000c -a -size -4002c`
for file in ${files}; do
        IFS="${OIFS}"

        echo "FILE [${file}]"
        (( c = c + 1 ))

        IFS="${NIFS}"
done

echo -e "\n$c"

Второй вариант это скинуть результат find во временный файл и потом его прочитать построчно но уже без пайпы ...

вот это вообще то что надо, только там так:

done <<< $(command)

кто-нибудь пояснит, что значит «<<<»?

как вы задолбали конвейеры строить.

Неявно заданные конвейеры не так задалбливают?

find ... -print0 | grep -c -z .

Для тех кто боится разных неудобных символов в именах

это не то, что тебе нужно. Find выдаст одну строку из-за $(find), и эта строка целиком уедет в цикл.

Т.е. будет _одна_ итерация, независимо от кол-ва файлов.

В моём примере никаких строк нет, в цикл направляется _файл_ (pipe), а не строка. Потому read читает по одной строке в каждой итерации из файла-пайпа.

Неявно заданные конвейеры не так задалбливают?

у меня тело цикла выполняется в том же потоке, что и всё остальное. Проблема будет только если ты внутрь <() додумаешься встроить изменения переменных. Но это уже совсем упороться нужно.

бояться надо идиотов, которые файлы называют с \n.

Про подстановку процессов

< <(find)

В коде башизмы узрел я.

там плохой пример с cat, которая ничего не делает. Если вместо cat цикл, то разница существенная.

ты в состоянии хотя-бы сабж прочитать?

Из man bash

Here Strings

A variant of here documents, the format is:

    <<<word

The word undergoes brace expansion, tilde expansion, parameter and variable expansion, command  substitution,  arithmetic  expansion, and  quote  removal.  Pathname expansion and word splitting are not performed.  The result is supplied as a single string to the command on its standard input.

Что сказать-то хотел?

Что сказать-то хотел?

хотел сказать, что башизмы тут в тему.

Пожалуйста-пожалуйста, я думал, ты сторонник #!/bin/sh.

я не люблю мазохизма. Зачем мне юзать POSIX shell из 70х годов? Это разве что в роутере оправдано.

шелл просто так \n не преобразует в строках, попробуй так

touch "$(printf "AA\nBB\nCC")"

так действительно сработает.

ну '\n' в названиях файлов это нонсенс

Традиционное наплевательское отношение башеводов ко всему, что не ложится на их баш с пайпами. А потом им файлы -rf мешают.

Традиционное наплевательское отношение башеводов ко всему, что не ложится на их баш с пайпами

Потому что нет инструмента, который мог бы учесть все частные случаи. Зато баш хорошо делает грубую грязную работу.

...Уходит обратно на нас поредевшая рота.
Что было — не важно, а важен лишь взорваный форт.
Мне хочется верить, что грубая наша работа
Вам дарит возможность беспошлинно видеть восход.

Потому что нет инструмента, который мог бы учесть все частные случаи.

Да ты же неосилятор.

find ... -print0 | while IFS= read -rd '' line; do
    # Do something with $line
done

Учел один частный случай, молодец. Перечитай еще разок, на что отвечаешь.

Ой, да у тебя к тому же пайпы, ну-ну. Изменить переменную попробуй внутри блока.

Учел один частный случай, молодец.

Какой частный случай, наркоман? Оно корректно работает со всеми возможными именами файлов.

Перечитай еще разок, на что отвечаешь.

Там ложь и псевдофилософствования.

Ой, да у тебя к тому же пайпы, ну-ну. Изменить переменную попробуй внутри блока

А пример без пайпов выше по треду мы проглядели? Ну, на, держи: http://mywiki.wooledge.org/BashFAQ/024#Workarounds

Есть же нормальные ЯП, без этого садомазо. Рубипитоны тоже делают быстро и хорошо.

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

такие файлы и в дельфине смотрятся как говно.

Есть же нормальные ЯП, без этого садомазо. Рубипитоны тоже делают быстро и хорошо.

сишка ещё быстрее и ещё лучше. К ней ещё autoconf, gettext и man page прикрутить можно. Только дебилы не понимают, что они потеряли, юзая баш для подсчёта числа файлов!

Там, где используется баш, C не всегда нужен. Т.к. часто нужно «быстро написать, сделать и забыть». А так, конечно, да. Хотя мне больше плюсы нравятся (for some values of «нравятся»).

Какой частный случай, наркоман? Оно корректно работает со всеми возможными именами файлов.

Ха-ха, а вот и нет, толстячок. Что скажешь про файл и символьный линк к нему?

А пример без пайпов выше по треду мы проглядели?

За чужую юбку прячемся?

Т.к. часто нужно «быстро написать, сделать и забыть».

ну и на кой ляд мне тащить везде этот твой руби? Руби, питон2, питон3, руст, гоу, паскаль, brainfuck, список можно продолжать до бесконечности.

Ха-ха, а вот и нет, толстячок.

Почему я — «толстячок»?

Что скажешь про файл и символьный линк к нему?

Скажу, что это не имеет отношения к «корректно работает со всеми возможными именами файлов». А find без -type находит все типы файлов, в т.ч. симлинки. Так что разворачивай мысль, а не виляй жопой.

За чужую юбку прячемся?

Ну, я же не должен всё писать за тебя. В треде и по моей ссылке достаточно информации, чтобы написать версию без пайпов самому.

Так что разворачивай мысль, а не виляй жопой.

В том-то и дело, что один файл находится дважды. Это как раз относится к «корректно работает со всеми возможными именами файлов».

В треде и по моей ссылке достаточно информации, чтобы написать версию без пайпов самому.

Слив засчитан.

мне тащить

Можешь продолжать страдать и делать час то, на что нужно 5 минут.

Можешь продолжать страдать и делать час то, на что нужно 5 минут.

ты точно уверен, что на руби быстрее сделаешь, нежели я на bash'е?

кстати, мой код УЖЕ здесь. А ты продолжаешь балоболить, лолка.

В том-то и дело, что один файл находится дважды. Это как раз относится к «корректно работает со всеми возможными именами файлов».

Нет, не относится — это два разных файла с разными именами. Иди, читай man find.

Слив засчитан.

Мда.

помощь

Да ты чего? проверяю ошибки на сайте , и тебе советую )

мой код УЖЕ здесь.

А должен быть на govnokod.ru

что не так в моём коде?

что не так в моём коде?

разве что в роутере оправдано

тормозный by-desingn и fork-ающийся на каждый чих shell

что не так в моём коде?

C=0
while read
do (( C++ ))
done< <(find)

Во-первых, как уже сказали, «файлы, в названии которых есть '\n' обработаются неправильно».

Во-вторых — будут некорректно обрабатываться \ в конце имён файлов: read без -r считает

line1\
line2

Можно заменить find на find -printf '\n'.