Это не совсем то, что вы думаете, но если вас интересует работа с файлами, поддерживающими метаданные, exiftool
может просматривать и изменять метаданные в большом количестве типов файлов, включая PDF-файлы. Полный список см. в man exiftool
.
Я неоднократно использовал его для создания и изменения метаданных в PDF-файлах. Например:
exiftool -Title="My PDF" \
-Subject="stuff" \
-Description="my pdf about various things" \
-Keywords="miscellanea, nonsense" \
-Author="me" \
-Creator="also me" \
"mypdf.pdf"
Теперь это становится более тесно связанным с вашей идеей. Поле Keywords
метаданных (или любое другое поле для тех форматов файлов, которые поддерживают создание произвольных полей -многие делают )для хранения ваших тегов в самих файлах,позволяя скрипту автоматически поддерживать ферму символических ссылок тегов.
В качестве альтернативы сценарий может поддерживать базу данных (неструктурированный -текст, например CSV или аналогичный, или базу данных SQL, например sqlite
), содержащую список имен файлов (с полным абсолютным путем ), метаданные файловой системы. (временные метки, размер, разрешение и т. д. )и их теги. Другие сценарии могут быть написаны для поиска в этой базе данных и возврата результата (s )в удобном формате.
Например:
vi $(search-tagged-files --date "last sunday" --keywords thesis)
или
localc $(search-tagged-files --keywords budget,2017 \
--mimetype=application/vnd.oasis.opendocument.spreadsheet)
ПРИМЕЧАНИЕ. :Единственным самым большим недостатком чего-либо подобного является огромный объем работы, который потребуется для поддержки тегов для каждого из файлов. Кое-что из этого можно было бы автоматизировать, но многое было бы утомительно, -ручная работа отнимала бы много времени. И это игнорирует время проектирования и разработки, чтобы придумать систему, чтобы сделать это.
Ни одна из программ, используемых для создания или редактирования файлов, не будет каким-либо образом интегрирована с такой системой управления файлами, как и стандартные инструменты, такие как mv
, cp
или rm
.
Вы могли бы написать сценарии-оболочки для многих из них, которые знали об этой базе данных тегов и обновляли ее автоматически, но я бы даже не знал, с чего начать, если бы вы использовали файловый браузер с графическим интерфейсом для перемещения, копирования и открытия файлов. и т.д... вам, вероятно, придется написать свой собственный файловый браузер.
Затраченная работа, вероятно, является основной причиной того, что большинство людей, у которых были подобные идеи, в конечном итоге подумали: «Вместо этого я просто буду использовать хорошо -организованное дерево каталогов». Даже работа, необходимая для написания кода для управления документами, огромна, а работа по управлению метаданными для каждого файла еще больше -, как правило, это стоит усилий только для очень крупных организаций, имеющих не менее десятков тысяч документов. следить за.
Это не новая идея,было проведено много исследований и разработок подобных идей. Одно из ее названий — Система управления документами .
Если вы хотите проверить каталоги, вы можете опустить -c
. И если вы хотите проверить размер, вам лучше опустить -h
и использовать -b
, чтобы получить размер в байтах.
Команду awk
можно использовать для отображения только тех строк, в которых первый столбец больше определенного размера:
Попробуйте:
du -bs /var/log | awk '$1 >= 1*(1024*1024*1024)'
И/или:
du -bs /var/* | awk '$1 >= 1*(1024*1024*1024)'
Если вы хотите найти файлы определенного размера, вы можете использовать утилиту find
, например:
find /var/log -type f -size +1G
Я вижу, что вы можете использовать команду du
с другой опцией.
ду -ч -д 1 -т 5Г
-h, --human-readable
print sizes in human readable format (e.g., 1K 234M 2G)
-d, --max-depth=N
print the total for a directory (or file, with --all) only if it is N or fewer levels below the command line argument; --max-depth=0 is the same as --summarize
-t, --threshold=SIZE
exclude entries smaller than SIZE if positive, or entries greater than SIZE if negative