v05i028: /etc/magic lines for compress

[Alexander Dupuy]

In article <470 at auspex.UUCP> guy at auspex.UUCP (Guy Harris) writes:
> The strings in "/etc/magic" correspond, in at least the
> two cases I cited (compressed files and packed files), to C-language
> strings; could somebody please explain why expressing them as numbers in
> a standard byte order, rather than as the strings they are, is somehow
> "better"?

Let me clarify the assertion that I made - that network byte order numbers are
better than strings.  I agree that if a magic `number' is actually recognized
as a character string by the applications which understand the format, that it
is better to make the entries in /etc/magic strings, since it is byte-order
independent, and clearer to someone looking at /etc/magic and trying to
understand it.  In the case of compressed or packed files, this does work well.

But there are other file formats (such as executables) which I would like to
recognize on machines with the opposite byte order.  This is very useful if you
have Vaxen and Suns sharing filesystems with NFS.  These are most naturally
represented as numbers, and in fact, I can't represent them as strings (since
some have 0-valued bytes, which cause problems in C strings).

By providing a network byte order implementation of file, I can use one version
of /etc/magic for all our machines, without having to worry about which entries
to byteswap when moving from one machine to another.  This is a useful
property, which is independent of the representational convenience of strings.

If I had to choose between using a file with strings with octal escapes or
using a network byte order version of file, I would choose the latter, since
the convenience in having one version outweighs the representational
convenience of strings in magic entries.  That was what I meant by better.
Someone working in a more homogenous environment might well make the opposite
choice, so `better' is a relative term.

Of course, the right solution is to support both.

@alex
-- 
inet: dupuy at columbia.edu
uucp: ...!rutgers!columbia!dupuy