[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFE: "-mtype" + -menc
From: |
L A Walsh |
Subject: |
Re: RFE: "-mtype" + -menc |
Date: |
Mon, 06 May 2019 16:20:31 -0700 |
User-agent: |
Thunderbird |
On 5/5/2019 9:50 AM, James Youngman wrote:
> On Wed, Apr 17, 2019 at 8:09 AM Bernhard Voelker wrote:
>
>> IMO starting to add one of such ideas to find(1) would open a can of
>> worms, like "what are my MP3 files with genre 'bluegrass'?".
>> Furthermore, there are specialized tools to do that, and it contradicts
>> the UNIX philosophy to not just use them.
>>
---
Not exactly -- we don't have a special 'cat' or 'grep' for music files
vs. photo files. We have 1 content agnostic util that works for both.
And before you can search for bluegrass, you have to know that you
want a music file.
Similarly if one wanted to search for a name, of a song, you might get
a song title, but of a picture, maybe a place or person; a creator
might return a composer for a song, but author for a book and
certainly genre for a book (S.F., fantasy) means something different
than genre for music or for a photo (nature, wildlife or people. In
order to do a search for a specific type of music or type of book, you
need to know it is music or a book, no?
Seems a meta-find would be useful there, but you need class to search
for a type where a label like 'bluegrass' makes sense. I could even
see 'bluegrass' returning a picture of Grass, showing 'Kentucky Blue
Grass' where the type was unknown.
Both Windows and Mac seem to have gotten the idea that such information
is stored in file-meta-information, vs. content meta-information.
Windows tries to do with file-extensions what Mac does with Xattr forks,
but Unix seem to be lost between file-status and file type, let alone
info based on content or metainfo, let alone type of file or
encoding of text info associated with a file.
Once you've narrowed down things to the type of file, you might
be able to select a content-specific tool for some specific field.
Some things are more associated with a person's relation to an
object like a ratings field or a play count vs. those things associated
with type of file, like a category or genre, or creator.
There are a couple of different levels of meta info, but I don't
really see any thing on unix/linux to even tell file type as
you usually get on windows or mac with the OS or tools that usually
come with the OS.
>
> I agree. Find should not open the files it searches (other than
> directories).
>
> Periodically, someone suggests extending findutils to add predicates
> relating to extended file attributes. A key challenge to implemeting
> this is to devise a generic interface (for the user of find) which
> isn't specific to one particular file system's type of file
> attributes.
Doesn't the Mac usually include info in a fork/metadata concerning the
type info that Windows attempts to get out of the file extension, and
a central DB of key-value pairs (registry)?
While file often peers into a file to give more info, much of what
file can do could be short-circuited by a unix DB/config file/or
kv-pairing.
> However, perhaps if such functionality were implemented,
> it would be possible for systems to add useful metadata (such as file
> type or musical genre) in such a way that find could match this.
>
Just a simple KV pairing that stays with UTF-8, it seems, could handle
much of that, more like a type of meta or registry file system, but
with better program-ownership and Time/data info to allow for better
housecleaning...
Think is, if it was a FS interface like proc/sysfs, "find" would still
be on the edge of usefulness because some things would be stored in
names, while other things might be stored in 'value' (or content) fields.