Jay West wrote: One trick I found, which I was surprised at, was that you seem to be able to 'cat' several mpeg files together into one and a player will happily play the entirety of the subsequent file. Weird; I mean most formats expect a single header and some data, but mpeg seems to be able to cope just fine with lots of header and data segments.

Adrian Graham wrote: No, you end up with an invalid target with multiple beginning-of-file headers throughout the file. -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

On 3/14/07, Adrian Graham <witchy at binarydinosaurs.co.uk> wrote: Cat just, um, cats. It has no knowledge of the contents of a file, but will happily squeeze together any amount of data you can fit from any source you can read from. Unlike the AVI format, MPEG-2 isn't utterly reliant on every detail in the headers being precisely correct. A well-behaved player will use what's in the header, but players I've used will keep attempting to play until they hit EOF or until the data looks so screwy that it causes serious problems to the decoder routines. What you may see from glommed MPEGs is a blip on the screen or a chirp file, but even that's not guaranteed to happen - it all depends on the particulars of the CODEC in use. MPEG, though, is reasonably tolerant of cruft passing though - like when there's a scratch or a speck of dust on a DVD, so it's unlikely to throw up its hands because it finds a few dozen bytes that don't decode to sensible video. With all of that said, I _think_ there's tools out there that can identify and remove those embedded headers. You wouldn't need the tool if everyone used "proper" tools to merge video, but since lots of people stitch MPEGs together with cat or COPY or whatever else, there's demand for the tool. -ethan

Ethan Dicks wrote: In the same way that dogs dog? :) That's certainly been my experience - just a short glitch between the file originals where it seems to drop a frame or two, then it just carries on. I didn't realise that it wasn't strictly part of the MPEG spec that you *couldn't* just cat files together and expect it to work on all players though, so my bad :) I think the mencoder app which comes with mplayer does this; I seem to recall reading somewhere that there's an option for recoding the data stream, which presumbly removes all the headers and writes a "correct" file. Never tried it on the few concatenated MPEGs that I have as I didn't think there was any need, but now perhaps I should!

On 15/3/07 05:16, "Jim Leonard" <trixter at oldskool.org> wrote: I was kind of taking the simplistic view that each file had a standard sized header that at least had a magic number* and some indication of length of said file. I can also see that it might just read-until-EOF so maybe I was crediting it with too much intelligence. *osf1/tru64 files have a magic number in the header that describes the file type which you can determine with the 'file' command. Since Tru64 is part BSD and part SYSV I thought said behaviour must've come from one of those. -- Adrian/Witchy Binary Dinosaurs creator/curator Www.binarydinosaurs.co.uk - the UK's biggest private home computer collection?

On Mar 15, 2007, at 3:58 AM, Adrian Graham wrote: Nope, there is no such header in any UNIX implementation that I'm aware of. The "magic number" you speak of isn't part of any header...the "file" program opens the target file, looks at the first few bytes, and then looks up the pattern in its database to arrive at an *educated guess* as to the type of file it's looking at...for example, if bytes 7-10 of the file are 0x4a464946 (ascii "JFIF"), it is most likely (but not definitely!) a JPEG image file. Similarly, if bytes 1-6 are 0x474946383961 (ascii "GIF89a") the file is most likely a v89a GIF image file, and if bytes 1-8 are 0xfeedface, it's a Mach-O executable from a MacOS X system. It is important to understand, though, that this has nothing at all to do with the operating system, and there is no common header format of any sort. It just so happens that many types of files are consistent in what their first few bytes contain. The "magic number" is just a pattern of bytes that are known to be consistent from file to file of the same type. Try this experiment on pretty much any UNIX-likesystem: apophis$ cat > foo.txt GIF89a is a half-decent file format. apophis$ file foo.txt foo.txt: GIF file, v89 apophis$ Similarly, if you create a file on a MacOS X system whose first eight bytes (not six!) are 0xfeedface, the "file" command will guess it is a Mach-O executable file...and if you happen to create a file whose first eight bytes are 0xfeedface, make it executable, and run it, the OS will attempt to execute it but fail. One of the primary tenets of the UNIX philosophy is that a file is NOTHING MORE than a sequence of bytes. This point is central and important enough that I'd argue that any UNIX implementation that adds such headers is no longer UNIX. Look at the man pages for the "file" command on your system to see where it stores its database. This is almost always a text file whose contents are well-commented; it will be fairly obvious how "file" uses it to scan a file to try to guess its type. -Dave -- Dave McGuire Port Charlotte, FL

On Mar 15, 2007, at 3:17 PM, Jules Richardson wrote: It used to be /etc/magic, but that has been changed in some systems. In current MacOS X, it's /usr/share/file/magic, for example. -Dave -- Dave McGuire Port Charlotte, FL

Andrew Burton wrote: It's hex. It's one of the "usual" hex patterns that "spell" out words using only 0-9 and a-f. Here are a couple of others that I've seen & used in projects: 0xdeadbeef, 0xc0edbabe. There are others, but I don't have them off the top of my head. -- TTFN - Guy

On Thu, 15 Mar 2007, der Mouse wrote: Microsoft .EXE files are differentiated from .COM files by the OS by looking for 'M' 'Z' as the first two bytes. Therefore, a .COM file could not start with DEC BP POP DX Was there really a Mark Zbikowski?

On 15 Mar 2007 at 16:05, Guy Sotomayor wrote: Bored programmers. On the CDC STAR, we had DEAD codes for system crashes. IIRC, DEADBEEF was the panic code for the pager faulting for a non-resident page (The pager can't page itself, so this was a "you can't get here from there" type of error). 64 bit hex does give you more than octal. We had DEADCACA, DEADFACE, etc. Some idiot used C0CAC01A as his "magic number"). This would be about 1972-73 on a 64-bit supercomputer. Is there a DEADBEEF that precedes this? When someone asks me "why use hex and not octal?", my response generally is "Because you can spell really stupid things with hex". Cheers, Chuck

Chuck Guzis wrote: The c0cac01a one is particularly clever! My personal favorite temp variables were the natural extension ones. For example, who can forget the first time they saw a FOO BAR and GRL? ;-) -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

It was thus said that the Great Jim Leonard once stated: I've used DECAFBAD as part of a user-defined MAC address (as DECAFBAD01)---nice thing about it was---it set the correct bits in the MAC address (single station, user defined address). -spc (And it certainly stood out in arp tables ... )

On 3/16/07, Ethan Dicks <ethan.dicks at gmail.com> wrote: Hmm... the Sun prefix is 08:00:20, so to be correct it'd be 08:00:20:c0:ff:ee. I've set the MAC address of several Sun machines to that, following the excellent guides on squirrel.org. Ed.

On 3/18/07, Jim Leonard <trixter at oldskool.org> wrote: It does indeed. *bangs head on desk* That'll teach me not to check a URL I think I can remember ... http://www.squirrel.com/sun-nvram-hostid.faq.html and its fellows. Ed.

de:ca:fb:ad:01 is one octet short of being a MAC. :) de:ca:ff:c0:ff:ee? Pity you can't use 21:35:00:c0:ff:ee (the first three octets being "not de:ca:ff". Hm, 02:13:50:c0:ff:ee?) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Thu, 15 Mar 2007, Chuck Guzis wrote: Um, all these examples are 32 bits only... I saw these things in Guru Meditations, too. The Amiga used DEADBEEF or DEADC0DE (or maybe both on different occasions?) Christian

On 3/16/07, Christian Corti <cc at corti-net.de> wrote: I don't think there were any uses of DEADBEEF within AmigaOS directly, but if you used Enforcer, a developer's tool, you might see those crop up. Enfircer did a number of things for you, including "enforcing" the sacredness of writing to low memory by fiddling with your MMU, if your Amiga had one, and posting alert boxes when predefined conditions triggered. There were a few places where one needed to run Enforcer just to do user tasks (like twiddling the cacheing of the 8MB Zorro-II memory space - required with the GG2 Bus+ for a variety of technical reasons), but most non-developer users never ran Enforcer, thus the only occurences of DEADBEEF or DEADC0DE would be if one ran some 3rd party application that happened to use it. -ethan

Guy Sotomayor wrote: I seem to remember "beachbabe" in an exam once. The examiners were rather apologetic :-)

arcarlini at iee.org wrote: That probably makes sense. Either way, it wasn't hex, which is what it was supposed to be :) (I suppose in these more politically correct times the examiners would be just as apologetic over the word itself...)

I've written C code to make an educated guess at something on the order of 100 file formats, ranging from the dirt-simple tagged formats where the header is guaranteed, to the more free-form script language. This was for the "recognizer" code in a program that translated between file formats. Although the UNIX purist might argue that all is bytes, in reality for many folks, they routinely deal with known file types created by a relatively few applications. Knowing what's inside a file and how the user likes to deal with it is a handy function of a computer, no? You might as well argue that you don't like standard filename extensions becaues filenames are just bytes. If you don't have file(1) and you don't have filename extensions, what do you have? A lot of files that you don't know what they are unless you can look inside. - John

Ethan Dicks wrote: I like the concept of the OS just "knowing" what a file contains without having an enforced name - but at the same time (and as someone else mentioned I think), extensions are useful to human beings in order to collate data (and to avoid the occasional mishap when the OS gets things wrong - as in Dave's GIF example) What really irritates though is people using modern OSes who are still stuck in the dark ages of DOS 3-letter extensions (people suffixing HTML markup files with "htm" rather than "html" etc.)

Ethan Dicks wrote: I think you mentioned VMS earlier. While it would be odd to call your program FOO.COM instead of FOO.EXE, you certainly could do so. To run it you would have to type $ RUN FOO.COM rather than just $ RUN FOO but if you did, it would work. Same goes for pretty much anything I can think of off the top of my head. The compilers certainly had defaults (e.g. FORTRAN would expect a .FOR file and procduce a .OBJ file) but you could override those if you wanted to. It's been too long for me to accurately remember how RT-11 handled things, but I _think_ it too allowed the FORTRAN-66 compiler to accept FOO.BAS as input. Antonio -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.11/723 - Release Date: 15/03/2007 11:27

On 3/16/07, Andrew Burton <aliensrcooluk at yahoo.co.uk> wrote: Umm... it's not about content - standard web _servers_ look at the extension and issue a line of text as part of the response to a query knows what MIME type to issue with .xhtml and .jhtml files. In my case, .htm and .html are Text/HTML files and are so described. It only starts to matter when you want to serve a file that's not of a known type (like when I've put Z-Machine files up for download). AFAIK, .xhtml and .jhtml are a known file type. When you say "VAX", I presume you mean under VMS. Dunno about text _and_ images, but Lynx should be easy to get working under VMS (it should be _trivial_ to get working under 4BSD or Ultrix). I don't have any experience with programming any workstation environments under VMS - text only for me, whether by serial cable and VT100 or by network port (DECnet, etc). It's not impossible to do it, even if your VAX has less than 16meg of physical memory (a VAXstation 2000, say), but I don't know if anyone has done it yet. There is a graphical browser for the C-64, IIRC. Surely one could match that level of performance with a VS2000. ;-) -ethan

On Fri, 16 Mar 2007, Andrew Burton wrote: I used to use Mosaic on a VAXstation 3100. I think there was also a version of Netscape for the VAX, but about that time those workstations were replaced with Suns. -- David Griffith dgriffi at cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?

Before all of that, we were putting Linx (Lynx?) on the Vaxes for users to access the web --- aaaah, pure text web surfing, those were the days ;-) Curt David Griffith wrote:

Certainly. But that's a long way from expecting cat(1) to recognize the headers on mpeg files and convert two header+data mpegs into header+data+data instead of header+data+header+data. Especially given the chance of misfires, with cat curdling data that happens to look a little bit too much like sokme format it knows but isn't. If you want to make basic tools like cat(1) smart about file types, you really need out-of-band file types, which Unix simply doesn't have. (Such a thing could be layered atop Unix, but the result wouldn't be very much like Unix any longer.) If they're advisory, I think they're a good thing. If they're compulsory, I think they're a very bad thing. Just like file types in headers. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

John Foust wrote: I'm seriously considering making use of the metadata facilities that some of the Linux filesystems provide [1] to be honest. I've held out until now because I don't like the idea of getting tied to one particular format - but no matter how much database and filesystem change notification (inotify etc.) is used, there are still "holes" where it's hard to keep the data and the metadata in sync if the metadata repository is layered on top of the filesystem. Anyway, it'd be personally useful not just for vintage archives but also for all these darn photos I keep taking of stuff (where a given image might fit into several logical "categories") :-) [1] Compulsory "vintage" question - what filesystem / platform was the first to allow arbitrary metadata to be included at the actual file level? cheers Jules

While working as a computer tech around 89-90 I was asked to install 2-3 of the damnedest things I'd ever seen. They were called Metaphors, and what was so cool about them was the front panel flipped down under the screen and out slide a wireless keyboard, wireless mouse and a keypad. They were GUI based, though for some reason I remember them being green on black or perhaps white on black monochrome screens. I set them up and someone else came in to connect them to a Metaphor server - apparently they needed their own proprietary server. So needless to say, while putting some stuff away in my office, I had some of my old notebooks from way back when and while fingering through the pages I notice - Amex - Metaphor install and remembered these funky little units - very slim and high tech for their time I have to say. Anybody own an actual unit and have some photo's? Curt

At 12:12 PM 3/16/2007, Adrian Graham wrote: Please don't. I intended no offense. To me, it's merely interesting that you thought it would do that. It's not a bad thing. As I pointed out, it's reasonable to expect that the concept - concatenation - remains useful in many contexts, and it would be useful to have a variant of 'cat' that understood multiple formats and did the appropriate action. For example, tell a Unix shell user you'd like to concat a thousand text files in a certain order and there's a bunch of ways to do it easily. But give a Windows user a thousand Word documents and ask then to merge - whew, suddenly you're tossed into a word of obscure third-party shareware tools that might or might not do the job. - John

I'm having great difficulty understanding this. AFAIK the cat(1) command doesn't have any knowledge of MPEG (or any other) file format. So it does the same thing with MPEG files that it does with all other files, namely copy the bytes to stdout. So if you have files of the form <header><data>, and if you then cat 2 of them together, surely the output is <header1><data1><header2><data2>. And not <modified header><data1><data2> or something like that. In other words catting 2 files will not produce a single header. What am I missing? -tony