л
можно. Я не понимаю, что ты пытаешься сделать - ты построчно читаешь файл $lift4search в переменную line и никак её не используешь
использую, в конвейере для find'а
Size: a a a
2020 September 29
F
использую, в конвейере для find'а
где???
л
где???
do find commands_convey >> "$work_dir"found.txt
F
do find commands_convey >> "$work_dir"found.txt
и где тут $line ?
️
while
read line
do find commands_convey >> "$work_dir"found.txt
done < $list4search
ранее объявленные директории
$list4search
$work_dir
как мне файл "$work_dir"found.txt обозначить в скрипте как переменную,
read line
do find commands_convey >> "$work_dir"found.txt
done < $list4search
ранее объявленные директории
$list4search
$work_dir
как мне файл "$work_dir"found.txt обозначить в скрипте как переменную,
while read -r line; do
find "$line"
done < "$list4search" >> "$work_dir/found.txt"EN
while read -r line; do
find "$line"
done < "$list4search" >> "$work_dir/found.txt"на каждую строчку дергать find?
л
на каждую строчку дергать find?
Да, а как иначе можно было скормить find'у список из файла?
F
Да, а как иначе можно было скормить find'у список из файла?
ну, теоретически, если диск большой и медленный, а процессор быстр - можно слепить имена файлов в один большой регексп и скормить его find -regex
аᶘ
ну, теоретически, если диск большой и медленный, а процессор быстр - можно слепить имена файлов в один большой регексп и скормить его find -regex
Лучше уж find из xargs вызывать с параллельным запуском.
аᶘ
Хотя вообще там, конечно, будет N обходов всего диска, что как бы тупо
F
Хотя вообще там, конечно, будет N обходов всего диска, что как бы тупо
я поэтому и уточнил "если диск большой". В небольшом диске все уйдет в кэш и второй обход быстр
аᶘ
я поэтому и уточнил "если диск большой". В небольшом диске все уйдет в кэш и второй обход быстр
Т.е. если айнод немного, то в оперативке останется информация обо всех айнодах к моменту конца первого обхода?
F
а вот ежели ты пишешь Дропбокс (у которого средний файл не больше 4мб) и решил работать с файлами, а не с s3...
F
me@fedora home_sweet_home]$ time find >/dev/null
real 0m9.496s
user 0m0.578s
sys 0m1.870s
[me@fedora home_sweet_home]$ time find >/dev/null
real 0m0.634s
user 0m0.245s
sys 0m0.382s
[me@fedora home_sweet_home]$аᶘ
Вообще я ведь правильно понимаю, что вся информация о дереве файловой системы (возьмём, условно, ext2) находится в суперблоке?
аᶘ
Просто если вся инфа в суперблоке, а для этого надо сдесяток мегабайт в RAM закинуть, то основное время работы find должно быть в обходе дерева, а не в чтении с диска.
F
Просто если вся инфа в суперблоке, а для этого надо сдесяток мегабайт в RAM закинуть, то основное время работы find должно быть в обходе дерева, а не в чтении с диска.
похоже на то