Re: Extended attributes
On Sat, 01 Jan 2000 10:41:17 +0100, the world broke into rejoicing as
Dirk Ritter <dirk@gnumatic.de> said:
> Hello Christopher Browne!
>
> On Fri, 31 December 1999 at 22:07:49, you wrote:
>
> [*.c associations]
> > ... And with a print utility ...
>
> And with an indentation tool and a source code analyzer and a spill
> checker and a documentation generation system and ... oh dear -
> where is bash - give my shell back to me and get me outta here! ;-)
Indeed.
> > I'm not sure that the EA necessarily needs to go with the file in this
> > case. I suspect that putting the control information in something
> > like unto ~/.mailcap
>
> Why record type information at all?
I didn't say "type information."
> I got curious and proved it -
> even 'file' as it exists today spits out type information for
> roughly 100 files within two seconds or less. Of course - I have
> a reasonably fast SCSI disk and 800 Bogomips, but when I ran it
> a second time it was just about as fast as a directory listing.
> Are you guys sure that information which can be gathered as fast
> is really worth recording? I have considerable doubts about it.
> Besides - 'file' already has great knowledge about file types, so
> why try reinventing the wheel? Why even think about the good old
> stone axe if you can do it with power tools?
> (Of course plain text vs. english text vs. not very english text is
> a bit spotty but this can be forgiven since 'file' even identifies
> a GNU/Linux Software Map as such (ever read about LSM entries?).) ;-)
I fully agree that using "file" is a tremendous idea. By the way,
if it's not fast enough as-is, reading through a text file, it would
make sense to build a version that hashes that into a DBM table, thus
reducing time and disk accesses to pretty much O(1).
[Parallel this with using a DBM'ed /etc/passwd file; many UNIXes come
with utilities that can compile /etc/passwd into /etc/passwd.dbm, so
that if the DBM file is there, and is newer that /etc/passwd, you can
get *real* fast access. Or look at the file I run "file" on, namely
/etc/aliases.db, which is another example of this...]
But this digresses from the *true* issue.
The *true* issue is not so much determining the file type as it is
determining what to do *as a result of the file type.*
We can use /etc/magic (or /etc/magic.dbm) to determine that the file
is of some type. For instance:
# file /etc/aliases.db
/etc/aliases.db: Berkeley DB 2.X Hash/Little Endian (Version 5, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2, Last Freed 0, Max Bucket 3, High Mask 0x3, Low Mask 0x1, Fill Factor 0, Number of Keys 0)
What that *doesn't* tell us is the *control* information of what program
to use to *process* it.
*THAT* is the thorny issue under discussion.
/etc/mailcap contains correspondences between MIME types and programs to
be used to process those types; *that* is what is being discussed.
--
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly)." -- Matt Welsh
cbbrowne@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Reply to: