Path: utzoo!attcan!uunet!mcvax!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.sources.bugs
Subject: Re: v05i028: /etc/magic lines for compress
Message-ID: <7714@boring.cwi.nl>
Date: 15 Nov 88 20:46:15 GMT
References: <1033@investor.UUCP> <454@auspex.UUCP>
Organization: CWI, Amsterdam
Lines: 33

In article <454@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
 > >>If you have a file(1) compatible with the one in sysVr3
 > >>adding the following lines to /etc/magic will make it
 > >>recognize compressed files.
 > >>
 > >>0	short		40223		compressed data
 > >>
 > >We have SysVr2.2 and the 40223 needed to be changed to 8093 (1F9D hex).
 > 
 > Person "A" had a little-endian machine (40223 is 9D1F hex) and person
 > "B" had a big-endian machine; the S5 release had nothing to do with it. 
 > 
 > Unfortunately, "strings" in "/etc/magic" cannot, in the standard S5
 > version, contain C-language escapes, so you can't do this:
 > 
 > 	0	string		\037\235	compressed data
 > 
 > which the SunOS version of the S5 'file" supports; this obviates the need
 > for byte-order-dependent versions of "/etc/magic".

It is clear that byte order dependencies are a pain, on the other hand
if for some system some format is specified as 0177767 it appears to be
backward to have to specify it in the form of a string.
Wouldn't it be better to allow specification like AR16W, AR32W and
AR32WR as happens in so many places in SysV (COFF comes to mind)?
Then each system can specify in its favourite order its own /etc/magic
part.  Of course file(1) would have to compose the words and longs
itself, but that is only minor.  (Note: this could also make a truely
portable file(1)).
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax