9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Jeff Sickel <jas@corpus-callosum.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: [9fans] a question of file and the history of magic
Date: Sun,  6 Jul 2008 13:16:52 -0500	[thread overview]
Message-ID: <011A09A5-865D-408B-831D-255ED03BBAF6@corpus-callosum.com> (raw)

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




             reply	other threads:[~2008-07-06 18:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-06 18:16 Jeff Sickel [this message]
2008-07-06 19:30 erik quanstrom
2008-07-06 21:00 ` Jeff Sickel
2008-07-06 21:20 erik quanstrom
2008-07-06 21:59 ` Brantley Coile
2008-07-06 22:31 ` Bakul Shah
2008-07-06 22:44   ` Charles Forsyth
2008-07-06 23:45 geoff
2008-07-07  8:58 Harri Haataja
2008-07-11 16:21 ` Dan Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=011A09A5-865D-408B-831D-255ED03BBAF6@corpus-callosum.com \
    --to=jas@corpus-callosum.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).