man magic (was Re: How to fix CRLF stuff... )


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