I remember the day I first saw a file magic file. I welcomed it because
for the first time I didn't have access to the source code. Those were
the days when you had to have $45k to get the source. A hard thing to
ask for. Today a separate magic file is just a leftover vestige of the
past. There are a lot of things like that. Do we still need to
compress man pages on 1TB disk driver? :)
erik quanstrom wrote:
In a sense, the question is more about the historical change and/or
adoption of a new file command for Plan 9 that doesn't use a magic
file for references. Why opt out of a magic file other than the
obvious performance hit of scanning it each run? Is it worth
repeating the old forms that used magic, or has anyone in the Plan 9
community already improved upon the idea and introduced a new, more
adaptable tool?
what is the upside to an external magic file? as you've shown, you
can add a file type in 1 line of code. while the external magic file
isn't c, i would argue that it's still code.
the disadvantage is that you need to write a parser for yet another
file format. it turns out that linux file's maintainers felt that a text file
wasn't good enough so they implemented a magic compiler. i really
don't understand the logic behind the compiler, since it would seem
to trade reduced cpu cycles for increased i/o. that would seem to be
a terrible trade off these days.
; wc magic magic.mgc
13469 69850 484372 magic
1301 17997 1062400 magic.mgc # compiled version
the source is pretty big, too:
; wc -l ffile-4.20/src/*.[ch]|grep total
9273 total
according to wikipedia (http://en.wikipedia.org/wiki/File_(Unix)),
system v introduced the external magic file. i don't think that system v
was in anyway an ancestor of plan 9. but i don't know anything of
the history of plan 9 file.
- erik
