This chapter is from the book
This chapter is from the book
This chapter is from the book
File Types and Extensions
The Unix side of Mac OS X might not care about what makes one kind of file different from another, but the graphical side certainly does. The "kind" of a file, which you can view by selecting it and then choosing File, Get Info, is what determines what kind of icon it has in the Finder and, more importantly, what application it opens in when you double-click it. This is pretty basic stuff, and it's familiar to anyone who's used a Windows PC or Mac anytime in the past 20 years.
What you might not be familiar with is just how Mac OS X identifies a file's kind. In the old, pre-OS X days, files on the Mac had an invisible four-letter "Type" code, along with another four-letter "Creator" code, the combination of which told the system what application the file belonged to and what other apps could open it if they advertised themselves as being able to open, for example, "JPEG" pictures or "MooV" movie files. Because these codes were invisible, nobody had to deal with them or even know they were there, and—even better—nobody had to put up with those ugly "extensions" they'd seen on files in Windows or MS-DOS. Why should you have to name a file "Shopping List.txt" when you could just call it "Shopping List" and have the system know it was a text file because of its TEXT Type code?
Mac OS X brought an end to that happy and elegant time, to many users' (and my) chagrin. Now, instead of Type and Creator codes, files were identified using extensions, just like in Windows: .txt for text files, .doc for Microsoft Word documents, .jpg for JPEG pictures, and so on. On the face of it, this looks like a huge step backward for usability. But what it really was was a nod to reality; the world in 2001 was dominated by Windows, and that meant that every file on the Internet had extensions, so we might as well get used to it. But Mac users don't have to like it. And that's why extensions in Mac OS X, after some early rough edges were sanded off, are handled with arguably even more slickness and flexibility than Type and Creator codes were.
You can hide the extension on a file, on a per-file basis (unlike in Windows, where either all extensions are shown or only the unknown ones are, as dictated by a global setting). Better yet, the way you hide an extension is by simply renaming the file: You click the filename, you put the cursor at the end, you backspace out the .txt or .doc, and it's gone, just as if the extension were any meaningless and disposable part of the filename. But it's not really gone: Do a Get Info on the file, and you'll find that the .txt or .doc is still there—the Name & Extension field shows the complete name, and the Hide Extension check box is checked. The system is similarly smart enough to figure out whether to hide or show the extension when you save a new file in TextEdit or Preview; if you specify the extension, it's shown, but if you don't, it's hidden.
Why is this useful? Why not just use Type codes like in the old days? Well, think about interoperability. If the filenames didn't have extensions, and you sent a text file or an MP3 song to someone using Windows, his computer wouldn't know what to do with it. Windows and Linux can't read Type and Creator codes, and those codes aren't included with files when transferred through popular Internet apps anyway. But if the extensions are there, and they're hidden only for the benefit of Mac users, then Windows and Linux users can still open the files using their favorite text editors or MP3 players, and Mac users can still look at pretty, extensionless filenames. Everybody wins!
Be aware that just because you don't see an extension on a filename in the Finder, that doesn't mean the extension isn't there. If you look at the file in the command-line shell, you'll see the whole filename, extension and all.