Re: RFE: "-mtype" + -menc

[L A Walsh]

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.