Subject: man magic (was Re: How to fix CRLF stuff... )
From: paul beard (pkdb1@home.com)
Date: Tue Feb 13 2001 - 12:37:09 EST
MAGIC(5) MAGIC(5)
NAME
magic - file command's magic number file
DESCRIPTION
This manual page documents the format of the magic file as
used by the file(1) command, version 3.30. The file com
mand identifies the type of a file using, among other
tests, a test for whether the file begins with a certain
magic number. The file /usr/share/magic specifies what
magic numbers are to be tested for, what message to print
if a particular magic number is found, and additional
information to extract from the file.
Each line of the file specifies a test to be performed. A
test compares the data starting at a particular offset in
the file with a 1-byte, 2-byte, or 4-byte numeric value or
a string. If the test succeeds, a message is printed.
The line consists of the following fields:
<snip>
on 2/13/01 9:22 AM, Jeremy Buchmann at jeremy@wellsgaming.com wrote:
> Okay, this seems to be getting very complicated...is there a more simple
> approach?
>
> For example, I use the Unix command "less" quite a bit to read through text
> files. But when I type "less picture.jpg", less tells me that it's a binary
> file. How does it know? I don't know exactly how it works, but I'm
> guessing it just scans the first few hundred or thousand bytes and checks
> for non-text/non-line-ending characters and if any are there, it reports it
> as a binary file. This may sound overly-simplistic, but it seems to work
> incredibly well. What do you think? Here are the pros and cons I could
> think of:
>
> Good Things:
> 1) Much more simple to implement
> 2) Should be pretty effective
>
> Number 1) is the main thing. Much less work, less complication, fewer bugs.
> As for 2), well it should be as effective as less if we used it's method of
> examining files (and I've never seen less be wrong).
>
> Bad Things:
> 1) It's not a perfect way of determining text/binary files.
> 2) It may be slower.
>
> Regarding 1), sure it's not perfect, but I think it'd be pretty darn good.
> I can think of a few things (like tar files with mostly text files and then
> a binary file at the end) that might thwart it, but those are special cases.
> Besides, can the dual-process-IPC method garantee 100% accuracy? As for 2),
> I don't think it'd be *that* slow (less can do it pretty quickly) and
> besides, when have Mac users been concerned with speed? No one buys a Mac
> because it's a speed demon.
>
> Thoughts?
>
> --Jeremy [jeremy@wellsgaming.com]
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:32 EDT