file(1) for z5/z8/etc?
Peter Seebach
My system currently says:
flat.z5: Hitachi SH big-endian COFF object, not stripped
which suggests that we don't have magic numbers.
-s
--
Copyright 2001, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
dgr...@cs.csuabk.edu
> Does anyone have an /etc/magic line suitable for recognizing z5/z8 files?
> My system currently says:
> flat.z5: Hitachi SH big-endian COFF object, not stripped
> which suggests that we don't have magic numbers.
What sort of system do you have? Most Linux and BSD systems in their
/etc/magic explain why there is no entry for zcode files: there are too
many collisions with other entries.
--
David Griffith
dgr...@cs.csubak.edu
Peter Seebach
>What sort of system do you have? Most Linux and BSD systems in their
>/etc/magic explain why there is no entry for zcode files: there are too
>many collisions with other entries.
Ahh, that would do it. *sigh*. I suppose it's a bit late to suggest a
canonical wrapper format. :)
David Glasser
> Does anyone have an /etc/magic line suitable for recognizing z5/z8 files?
You can try the one in /if-archive/utilities:
<http://www.ifarchive.org/if-archive/utilities/magic>
--
David Glasser
ne...@davidglasser.net http://www.davidglasser.net/
Andrew Plotkin
> In article <a0jm97$21nst$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:
>>What sort of system do you have? Most Linux and BSD systems in their
>>/etc/magic explain why there is no entry for zcode files: there are too
>>many collisions with other entries.
(Specifically, if it begins with the byte 05 it's a Z5 file... etc.)
> Ahh, that would do it. *sigh*. I suppose it's a bit late to suggest a
> canonical wrapper format. :)
Blorb is closest.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Daniel Dawson
written by David Glasser <ne...@davidglasser.net>. It says:
>You can try the one in /if-archive/utilities:
><http://www.ifarchive.org/if-archive/utilities/magic>
Debian seems to have included the contents of that file in
/usr/share/misc/magic, but commented out the Infocom stuff, for the reason
already discussed in this thread.
--
Daniel Dawson
dda...@nospam-altavista.net (remove 'nospam-' to send mail)
David Glasser
> You pick up and read article <1f56kbl.1m2po4r9rovc6N%ne...@davidglasser.net>,
> written by David Glasser <ne...@davidglasser.net>. It says:
> >You can try the one in /if-archive/utilities:
> ><http://www.ifarchive.org/if-archive/utilities/magic>
>
> Debian seems to have included the contents of that file in
> /usr/share/misc/magic, but commented out the Infocom stuff, for the reason
> already discussed in this thread.
Well, hmm. There are lots of collision, but what are they with? The
original poster's system had "Hitachi SH big-endian COFF object, not
stripped". I have no real clue what that is (compiled code, I guess),
but if you're more likely to have Z files than that, it could be worth
it.
Peter Seebach
David Glasser <ne...@davidglasser.net> wrote:
>Well, hmm. There are lots of collision, but what are they with? The
>original poster's system had "Hitachi SH big-endian COFF object, not
>stripped". I have no real clue what that is (compiled code, I guess),
>but if you're more likely to have Z files than that, it could be worth
>it.
Yeah - but, unfortunately, on NetBSD, you're probably more likely to have
COFF objects; I think that'd be binaries from the Dreamcast port.
:)
dgr...@cs.csuabk.edu
> Peter Seebach <se...@plethora.net> wrote:
>> In article <a0jm97$21nst$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:
>>>What sort of system do you have? Most Linux and BSD systems in their
>>>/etc/magic explain why there is no entry for zcode files: there are too
>>>many collisions with other entries.
> (Specifically, if it begins with the byte 05 it's a Z5 file... etc.)
Perhaps there is some other constant that one typically finds in a zcode
file. Anyone have any ideas?
--
David Griffith
dgr...@cs.csubak.edu
Daniel Dawson
>Perhaps there is some other constant that one typically finds in a zcode
>file. Anyone have any ideas?
If there is, the Z-Machine standard should hold a clue.
D. Jacob Wildstrom
Daniel Dawson <dda...@nospam-altavista.net> wrote:
>If there is, the Z-Machine standard should hold a clue.
There's very little in there which is 100% effective, since so many of
the header values are addresses of various tables (pretty much
uncheckable) or properties of the datafile which don't have really
rigid standards (for instance, the file length does _not_ have to be
identical to the 'file-length' field of the header). A couple
moderately effective heuristics though:
Check that position 0x12-17 contain digits only. With a couple of
exceptions (early versions of Zork I & II, one version of Suspended,
and one of LGOP, I believe), this is true of Infocom games. This
standard is true of, AFAICT, almost all Inform games, since this
requirement is actually hardcoded into Inform (l. 591 of directs.c in
the 6.21 soruce, for anyone actually curious) -- recompilation of
Inform, or bit-twiddling of the resultant z-code, could change this,
but that's not terribly common.
The interpreter-set fields (at least half the bits of 0x01, 0x1E-27)
are, I think, originally zero in shipped story files/ Inform
compiles. I'm less sure on this one.
Happy new year, all!
+--First Church of Briantology--Order of the Holy Quaternion--+
| A mathematician is a device for turning coffee into |
| theorems. -Paul Erdos |
+-------------------------------------------------------------+
| Jake Wildstrom |
+-------------------------------------------------------------+
OKB -- not okblacke
>Check that position 0x12-17 contain digits only. With a couple of
>exceptions (early versions of Zork I & II, one version of Suspended,
>and one of LGOP, I believe), this is true of Infocom games. This
>standard is true of, AFAICT, almost all Inform games, since this
>requirement is actually hardcoded into Inform (l. 591 of directs.c in
>the 6.21 soruce, for anyone actually curious) -- recompilation of
>Inform, or bit-twiddling of the resultant z-code, could change this,
>but that's not terribly common.
For what it's worth, I'd advise against using this check, simply because I
think it's silly for the compiler to arbitrarily restrict the serial "number"
like this, and I hold out a hope that tons of people will subvert this
oppressive restriction and make serial strings! (My irritation is perhaps
excessive, but my aversion is real.)
--OKB (Bren...@aol.com) -- no relation to okblacke
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Alnutway Petrofsky
> Check that position 0x12-17 contain digits only.
I was also thinking that this, combined with a check that the first
byte is 1 through 8, would leave an acceptably remote possibility of
error (which is all that can be said of any magic number check).
Unfortunately, such a test is beyond what can be expressed in the
magic file.
It would probably even be sufficient to check that the first byte is 1
through 8 and that byte 0x14 (first digit of the month) is 0x30 or
0x31 ('0' or '1'), but even that is a little beyond what /etc/magic
can specify.
-al
Matthew Russotto
Peter Seebach <se...@plethora.net> wrote:
>Does anyone have an /etc/magic line suitable for recognizing z5/z8 files?
> FILE, RECOGNIZE ZCODE
Sorry, Infocom didn't work that way.
--
Matthew T. Russotto mrus...@speakeasy.net
=====
Dmitry is free, but the DMCA survives. DMCA delenda est!
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Matthew Russotto
Lots, but the magic format can't handle them. If you check for the
first byte and for 6 digits at $12, you'll get all but a few old games
and corrupted versions. But magic can only test one thing at a time,
and can't check for digits.
Alpine Petrofsky
> In article <a0qkqo$2264i$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:
> >Perhaps there is some other constant that one typically finds in a zcode
> >file. Anyone have any ideas?
>
> Lots, but the magic format can't handle them. If you check for the
> first byte and for 6 digits at $12, you'll get all but a few old games
> and corrupted versions. But magic can only test one thing at a time,
> and can't check for digits.
The test below seems to work pretty well. It checks that the seven
unused bits of Flags 2 are all zero, and that the first two characters
of the serial number are in the set [0-9:;<=>?]. This doesn't
directly conflict with anything else in the magic file. Because it
only checks 15 bits, this rule will match 1 in 32k random binary
files. Judging by other magic entries, that appears to be acceptable.
I just checked it on my debian linux system, and there were only two
false positives in 100k files: /usr/share/texmf/omega/ocp/
char2uni/inbig5.ocp and a second copy of the same file. That's a
pretty obscure file for which the standard magic provides no useful
information anyway.
16 belong&0xfe00f0f0 0x00003030 Infocom game data
>0 ubyte x (Z-machine %d,
>2 ubeshort x Release %d,
>18 string >\0 Serial %.6s,
>26 ubeshort x Size 0x%4x)
If nobody here has any better ideas or reports significant false
positives, then I'll send this in to Zoulas (the arbiter of unix
magic).
-al
Daniel Dawson
>I was also thinking that this, combined with a check that the first
>byte is 1 through 8, would leave an acceptably remote possibility of
>error (which is all that can be said of any magic number check).
I, too, thought of this check. I also think it would greatly increase the
likelyhood of a correct identification. (I do wish file(1) could also check the
file extension; that would really help.)
>Unfortunately, such a test is beyond what can be expressed in the
>magic file.
Not so. It probably *would* be more effort than is usually expended on
magic(5), but it's possible. Let me try:
18 byte >0x2f
>18 byte <0x3a
>>19 byte >0x2f
>>>19 byte <0x3a
>>>>20 byte >0x2f
>>>>>20 byte <0x3a
>>>>>>21 byte >0x2f
>>>>>>>21 byte <0x3a
>>>>>>>>22 byte >0x2f
>>>>>>>>>22 byte <0x3a
>>>>>>>>>>23 byte >0x2f
>>>>>>>>>>>23 byte <0x3a
>>>>>>>>>>>>0 byte 0x3 Z-Machine story file: version 3,
>>>>>>>>>>>>>2 beshort <0x7fff release %3d,
>>>>>>>>>>>>>26 beshort >0 size %d*2,
>>>>>>>>>>>>>18 string >\0 serial %.6s
Hehehe! There you go! Unless I missed something in the manpage, that should
work. Just repeat for the different Z-Machine versions, or maybe just add
checks for the version number. Of course, that would require descending to even
deeper '>' levels.
Now, who wants to put this beauty on the archive? :)
Albuminosis Petrofsky
> It probably *would* be more effort than is usually expended on
> magic(5), but it's possible. Let me try:
>
> 18 byte >0x2f
> >18 byte <0x3a
> >>19 byte >0x2f
> >>>19 byte <0x3a
...
> Hehehe! There you go! Unless I missed something in the manpage, that should
> work.
Sorry, this will catch all files whose first byte exceeds (signedly)
0x2f (which is almost a third of all files), and fail to run any more
tests on them after the z-machine tests. Alas, ">" lines can only be
used to print additional information, they cannot be used to reduce
the number of matches.
But see my article from earlier today for a pretty-good solution.
-al
Daniel Dawson
>Sorry, this will catch all files whose first byte
Uh, you mean 19th byte.
>Alas, ">" lines can only be
>used to print additional information, they cannot be used to reduce
>the number of matches.
Ack! You're right! I should have realized that. Well, anyway, your solution is
pretty good.
I still think that checking the file extension would be useful, for
disambiguation if nothing else. What do you think?
Alapalooza Petrofsky
> I still think that checking the file extension would be useful, for
> disambiguation if nothing else. What do you think?
Possibly, but extending file to do that would be a lot more work than
I'm up for. Also, after decades of the current behavior, there would
be confusion and bug reports if file started returning different
results for files with identical contents. Furthermore, the todo list
for file already includes a more powerful feature, regexp matching,
that wouldn't violate people's expectations.
-al
Daniel Barkalow
For that matter, one mostly uses file if the filename doesn't help, which
means that file will mostly see z-machine games named "game.dat" (iirc).
-Iabervon
*This .sig unintentionally changed*