v05i028: /etc/magic lines for compress

[Dik T. Winter]

In article <470 at auspex.UUCP> guy at auspex.UUCP (Guy Harris) writes:
 > >Not only is this better,
(Specifying native byte order.)
 > 
 > This assertion has now been made twice.  I have yet to see any evidence
 > for its truth.  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"?

Ok, ok, I did not look at the source before posting, and indeed, compress
uses a string (I still did not look at pack).
The reason it is better is when you have executables for different systems
(with different byte order, that is).
Why should I have to specify for a Sun executable:
2	short	05401
on a Vax, or for a Vax on the sun:
0	short	05401
?
Why not something like (possibly I have AR16W and AR16WR wrong, and AR16WR
does not exist, I believe):
2	AR16WR	0413	Sun executable
0	AR16W	0413	Vax executable
which (with a proper implementation of file) will work on both systems?

The public domain implementation contained a file for Vax executables,
an excerpt follows:
0	long		00700200000	VAX executable
0	long		01000200000	VAX pure executable
0	long		01300200000	VAX demand-paged pure executable
0	long		01100200000	PDP-11 executable

Do you see the relationship with 0407, 0410, 0411, 0413 from a.out.h?
And will it work on a Vax?

The CDC Cyber 180 series have a layered implementation of Unix (VX/VE) with
a quite right implementation; from /etc/magic:
0       vlong           0100554         apl workspace
0       vshort          0407            Vax 11-750/780  - executable

I hope I convinced you of the suitability of specifying byte order,
but I doubt it.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik at cwi.nl
BITNET/EARN: dik at mcvax