Bug 12554

Comment 1 Sheldon Hearn 1999-07-09 13:17:11 UTC

State Changed
From-To: open->feedback

Are there any precendents for game-related formats in the existing Magdir? 

Yes there are precedents for games file formats. Look at
/usr/src/usr.bin/file/Magdir/adventure.

--lyndon

The two most common elements in the universe are Hydrogen and stupidity.
					-- Harlan Ellison

Hi David,

I've looked at the precedent which you offered for having game file(1)
formats in the base system. I'm pretty sure that the Infocom file format
is used by a game in the base system.

I'll tell you what's making my skin crawl, here. I worry about having a
hugely bloated src/usr.bin/file/Magdir in our source tree. Now that does
seem like a counter-productive paranoia, but I can't shake it.

Since file(1) already has a command-line option (-m) for specifying
additional magic files, here's what I propose. I'd like to modify
file(1) so that it honours an environment variable, perhaps MAGDIRS. The
variable includes a colon-separated list of paths to additional magic
files.

The idea is that your port would include an install-time message that
says something like "add MAGDIRS=${PREFIX}/share/misc/magic to
/etc/profile so that file(1) will recognize WarCraft2 save files".

What do you think?

Ciao,
Sheldon.

That's definitely a possiblity.  I'm not overly concerned whether or not this
makes its way into the system magic file, I just thought some people might like
it.  Your ports idea is a good one; however, here are my thoughts on the 
matter:

I think file(1) should have as "bloated" a magic database as possible.  I think
if file(1) recognized every possible file format on earth, that would be really
cool.  If the ascii format magic file is already beginning to show a speed
hit from the current amount of bloat, I think file(1) should move to a database
format.  I assume the internal file(1) code already uses some type of tree
based search which is efficient, so it's just a question of precompiling the
data into a binary-format magic file.  But I digress.  The argument of "blah
is used by the base system" is obviously pointless as there's Excel, Word,
etc etc files in there.  "But people deal with those all the time for one
reason or another in FreeBSD and there are programs that do stuff with them
under FreeBSD like StarOffice".  Indeed, but those aren't in the base system.
They are, however, very useful.  In general being able to recognize any 
arbitrary piece of binary data (and not have it come up "troff macro file"
like lame Unices with neutered magic files do) is a very very good thing.
I'd like to see the magic file grow.  

But that's just my opinion.

(As for the bloat of it being in the source tree, I can't see it ever, ever
approaching the size of..say.. Perl 5)

> 
> Hi David,
> 
> I've looked at the precedent which you offered for having game file(1)
> formats in the base system. I'm pretty sure that the Infocom file format
> is used by a game in the base system.
> 
> I'll tell you what's making my skin crawl, here. I worry about having a
> hugely bloated src/usr.bin/file/Magdir in our source tree. Now that does
> seem like a counter-productive paranoia, but I can't shake it.
> 
> Since file(1) already has a command-line option (-m) for specifying
> additional magic files, here's what I propose. I'd like to modify
> file(1) so that it honours an environment variable, perhaps MAGDIRS. The
> variable includes a colon-separated list of paths to additional magic
> files.
> 
> The idea is that your port would include an install-time message that
> says something like "add MAGDIRS=${PREFIX}/share/misc/magic to
> /etc/profile so that file(1) will recognize WarCraft2 save files".
> 
> What do you think?
> 
> Ciao,
> Sheldon.
> 

--David Bushong

On Mon, 19 Jul 1999 12:14:55 MST, David Bushong wrote:

> I think file(1) should have as "bloated" a magic database as possible.
> I think if file(1) recognized every possible file format on earth,
> that would be really cool.

You motivate the case for file(1) magic bloat very well. :-)

So how about a deal? You gimme magic for Orcs&Humans (WarCraft I),
WarCraft II (PC) and I'll commit them along with your one all in one go.
That is, unless I've missed the point and your game uses the same game
file format as the Blizzard game.

Deal?

Ciao,
Sheldon.

> On Mon, 19 Jul 1999 12:14:55 MST, David Bushong wrote:
> 
> > I think file(1) should have as "bloated" a magic database as possible.
> > I think if file(1) recognized every possible file format on earth,
> > that would be really cool.
> 
> You motivate the case for file(1) magic bloat very well. :-)
> 
> So how about a deal? You gimme magic for Orcs&Humans (WarCraft I),
> WarCraft II (PC) and I'll commit them along with your one all in one go.
> That is, unless I've missed the point and your game uses the same game
> file format as the Blizzard game.
> 
> Deal?
> 
> Ciao,
> Sheldon.
> 
The game I was working on, "XCraft" is a clone of WarCraft II, and thus used
the same file format for maps (PUDs).  I do not own WarCraft I, and don't
really know what format its maps used, however, I could probably hunt it up
on the net and throw something together, except that I don't think anywone
ever really cared about War I format map files (I didn't see any user made
ones distributed, etc etc)  Now some StarCraft .scm and .scx magic might be
useful, if only they didn't compress/encrypt their maps with no discernable
way to determine anything about them (except for that they are SC maps)..
here's the magic to recognize them:

#------------------------------------------------------------------------------
# starcraft: file(1) magic for StarCraft MPQ (data) files
#
# From:  David Bushong <david@bushong.net>
#
0       string          MPQ\32\ \0\0\0                  StarCraft MPQ Data

which could possibly be tossed together with warcraft2 into a "blizzard" file,
but I avoided doing that before to avoid using a company name as a file name.

--David Bushong

Hi David,

I've had some good advice from David O'Brien on the issue of what to
call the file in which your new addition goes. He suggested that, since
is actively maintained by Christos Zoulas <christos@deshaw.com> (yes, it
should really be in contrib), we should send the man e-mail with
submissions and let him decide where to put them. :-)

Then we can import his updates into our own version without heart-ache,
knowing that the guy who looks after the package made the decision
himself.

Would you like to mail your contributions to Christos and keep PR 12554
in the loop?

Ciao,
Sheldon.

Hi David,

I'd like to know whether you've had any feedback from the file(1)
maintainer regarding your submission. If you have, I'd like to close the
PR, since you can open another PR when a new release of file(1) is
available for import. :-)

Thanks,
Sheldon.

Comment 9 Sheldon Hearn 1999-08-30 13:39:16 UTC

State Changed
From-To: feedback->closed

Originator will filea new PR when the maintainer has included his 
submission in a new release of file(1).