"File types"

Chuck Guzis wrote: No, those are file *permissions*. By "type", I mean: "This is a photograph" "This is a MSWord 'document'" "This is a TIFF image" "This is a C source file" "This is a C++ header file" etc. Granted, file(1) can deduce file types of many files. I am not advocating that such a mechanism is necessary or should exist. Rather, I am asking why foo.jpg now is almost universally regarded as a JPEG photographic image, why foo.doc is an MSWord file (before MS came along, .DOC files *typically* were simple text files containing notes (DOCumentation), etc. E.g., ages ago, a *helpful*/accommodating application would automatically append a suffix to a filename that you specified on the command line (e.g., "asm foo" would be interpreted as "asm foo.src" if "foo" -- no suffix -- did not exist) but wouldn't *require/enforce* this "convention". So, I could do "asm foo.obj" if I had a perverse sense of humor *and*, as long as "foo.obj" contained valid "src code", the application would process it as such. But, nowadays, systems seem (excepting Macs?) to all tie some significance to the "extensions" tagged onto filenames. E.g., they gag on files named "MyFile", "ReadMe", etc. because they can't infer the file type from the name (lacking a suitable "extension"). It seems that this represents a net *loss* (IMHO) as now namespaces are cluttered with stuff *besides* names. And, it can screw the unwary (e.g., even CVS silently changes its behaviour in how it treats a file depending on the name assigned to that file -- CVS one would think would be very wary of dicking with a file's contents haphazzardly)