This is a comment/question about file(1) as implemented in Plan 9 and
p9p.
Over the years I've been using various versions of file with editable
magic files. Though file "can make mistakes", this worked out rather
well when I just wanted a little more detail than 'binary' with the
tradeoff of the command being a bit slow at times. While deciding to
use p9p's rc for a script to help with some picture process, I
realized I needed to use file to help determine the type of data I'm
checking on the file system. So I added the following (though it
could just be added to the long0tab just as easily):
% hg diff file.c
diff -r d7799c860a8f src/cmd/file.c
--- a/src/cmd/file.c Sat Jul 05 10:01:43 2008 -0400
+++ b/src/cmd/file.c Sun Jul 06 12:30:28 2008 -0500
@@ -655,6 +655,7 @@
"\377\330\377\340", "jpeg", 4,
"image/jpeg",
"\377\330\377\341", "jpeg", 4,
"image/jpeg",
"\377\330\377\333", "jpeg", 4,
"image/jpeg",
+ "\106\117\126\142", "x3f", 4,
"image/x3f",
"BM", "bmp", 2,
"image/bmp",
"\xD0\xCF\x11\xE0\xA1\xB1\x1A\xE1", "microsoft office document",
8, "application/octet-stream",
"<MakerFile ", "FrameMaker file", 11,
"application/framemaker",
This addition helped my scripts become a little more streamlined, but
of course puts in an additional entry into the source file I need to
track. As file name extensions don't always work across all sorts of
systems, many still hamstrung by 8.3, what is the preferred or
recommend mechanism for checking file types the Plan 9 way since we no
longer have the System V magic?
In a sense, a modified xd(1) that has an option for a restricted range
of byte sequences would work. That would at least provide a fast seek
into a file that can be pipelined into any other command sequence--no
need to dump the whole file when you just need to the first four
bytes, but then it just gets to the point of having a magic file.
-jas
