URL:
<https://savannah.gnu.org/bugs/?64253>
Summary: Suggestion - Add support for libmagic and xattr
Group: findutils
Submitter: None
Submitted: Thu 25 May 2023 07:18:47 PM UTC
Category: find
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Originator Name: Jay
Originator Email: the-m...@github.com
Open/Closed: Open
Release: None
Discussion Lock: Any
Fixed Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Thu 25 May 2023 07:18:47 PM UTC By: Anonymous
I've gone through past patches, bugs and suggestions and I was surprised I
could not find any mention of the obvious idea of adding support for libmagic
(magic | file | etc), so thought that it might be a useful feature to find,
here are some ideas.
Also while I think about this, and with the growing use of extended attributes
by applications, it may also make sense to think about including some sort of
xattr filter too.
Most filesystems on which find is er..., found, have xattr capability and it
has been present in almost all contemporary operating systems kernels for the
best part of two decades.
[https://man7.org/linux/man-pages/man7/xattr.7.html man xattr]
Homepage here:
[https://www.darwinsys.com/file/ file | magic | libmagic]
Google have convinced ICANN that file extension like TLDs such as '.zip' are a
good idea. This sets a ball rolling, others will folow. This means OSs will
finally have to adapt and accept that deciding what a file is for, just based
on a parts of the given file name is naive and will have to make use of the
actual contents (as IMO as they should have a long time ago). Very soon
extensions mean little other than a hint to the human.
[https://www.wired.com/story/google-zip-mov-domains-phishing-risks/ WIRED]
Features like these would allow searching of folders for type rather than
extension, without extra levels of scripting.
e.g.
Currently - without find : this is inefficient as we can't add filter without
adding code and we are already spawning thousands of find instances.
for f in ./*; do
if [[ $(file -b $f) == ".*PE32 executable.*" ]]; then
my_command $f;
fi;
done
Currently - with find : We need xargs and sed and so have to worry about
whitespace paths and filenames, we are also spawning several sub-commands.
find -type f |
xargs file |
sed -n 's/:.*PE32 executable.*/p' |
xargs my_command
Conceptual new usage (syntax usage tbd)
# For libmagic
find . -magic ".*ELF.*x86_64.*" -not -path "./bin/*" -exec my_command {} \;
find . -mime ".*application/x-dosexec.*" -not -path "./bin/*" -mv {}
/Quaranteen/
# For xattr
find . -xattr 1 app.browser.url -xattr-substr 1 "http://download.org"; -delete
find . -xattr 1 os.hash.blake2 -not -xattr-re 1 "^ERROR:bad hash.*" -exec hash
whirlpool {} ;\
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64253>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
