Так как Вы заявляете, что это - домашняя работа, я дам Вам ряд подсказок, а не решения.
Можно запустить с чего-то вроде этого:
find . -type f|xargs -I% md5sum % |sort \
|uniq -w32 -D|cut -f3 -d' '|while read filename ; do
# code here
done
В этом while
цикл, filename
будет содержать название одного из файлов, обнаруженных Вашим конвейером.
Идея состоит в том, чтобы сравнить каждого с предыдущими файлами. Чтобы сделать это, в конце цикла, добавляет текущий файл к массиву:
count=0
find . -type f|xargs -I% md5sum % |sort \
|uniq -w32 -D|cut -f3 -d' '|while read filename ; do
# code here
files[$cout]="$filename"
count=$((count+1))
done
Все, в чем Вы нуждаетесь теперь, должно заполнить #code here
:-) Вы имеете в Вашем распоряжении:
$filename
files
массив$count
(не упустите ошибки диапазона),Можно уладить все это с a while
цикл, сравнивая файлы $filename
и ${files[$some_counter]}
на каждом шаге.
Для создания этого лучше необходимо только проверить файлы с тем же md5sum
друг против друга. Для этого Вы могли:
cut
от Вашего конвейераread
читать и в сумме md5 и в имени файлаfiles
выстройте, когда Вы обнаруживаете, когда Вы идете дальше к другой сумме md5Этому будет нужна еще одна переменная для отслеживания "текущую" сумму md5.
Можно сделать его еще лучше путем предотвращения избыточных сравнений. Для этого необходимо будет добавить немного больше логики, чтобы не добавлять файл к files
если это уже идентично одному в том массиве.
И можно обойтись без $count
переменная.
И что-то очень важное необходимо проверить (и зафиксировать при необходимости): удостоверьтесь свои работы сценария с именами файлов или именами каталогов, которые содержат пробелы.
Читайте на массивах удара.
"Верхняя память" и "низкая память" не относятся к виртуальному адресному пространству процессов, это о физической памяти вместо этого.
В виртуальном адресном пространстве процесса пространство пользователя занимает первых 3 ГБ, и ядро располагает четвертый ГБ с интервалами этого линейного адресного пространства.
Первые 896 МБ пространства ядра (не только код ядра, но и его данные также) "непосредственно" отображается на первых 896 МБ физической памяти. Это является "прямым" в том смысле, что всегда существует смещение 0xc0000000 между любым линейным адресом этой части 896 МБ пространства виртуального ядра, и его соответствующий адрес в физической памяти (обратите внимание однако, что MMU включен и что записи таблицы страниц на самом деле используются для этого).
Последняя часть 128 МБ пространства виртуального ядра - то, где отображаются некоторые части физической "верхней памяти" (> 896 МБ): таким образом это может только отобразить не больше, чем 128 МБ "верхней памяти" за один раз.
Ссылка: "Понимание Ядра Linux", третий выпуск - разделяет "8.1.3. Зоны памяти" и "8.1.6. Отображения ядра Страничных блоков Верхней памяти".