[Top][All Lists]

[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

>  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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]