Quirks In File And Folder Naming (Part 2)

The greatest anomaly in the use of filename extensions is in files consisting of executable code, such as command shell tools. Shell scripts normally have the exten­sion .sh if they’re to be run in a command shell, such as in the Terminal application, but are editable text files. All executable code files, including background services, com­mand tools and even the code contained within applications are named without any extension. This is to conform to standard UNIX practice, rather than the Windows tra­dition of .exe and .com.

Driven is extraction. When you need to extract and install separate components that are only available in a larger Installer Package, use Pacifist

For traditional Mac users who had come to love freedom from the mechanical disci­pline of file naming conventions, the rise of filename extensions may seem to be a sell­out to the UNIX and Windows world. In fact, these extensions enrich and enhance, and should only very seldom trip you up once you understand their whys and wherefores. They’re essential to maintaining the wonder­ful illusions worked by the Finder and OSX, and keeping your work productive.

For normal purposes, the PackageMaker tool provided in Xcode is of limited value, but it comes into its own if you create or modify packages

Inside a .app file

An application with the .app exten­sion seems, in the Finder, to be a single object with its custom icon for identi­fication. In fact, what you see is a pure illusion created by the Finder, as it’s really a folder containing a fairly rigor­ous structure of sub-folders and files with different functions. Select the application icon in a Finder window and Ctrl-click to bring up the Finder’s contextual menu, which contains the Show Package Contents command to open it as a folder.

At the top level, all applications folders with the extension .app - contain a single wrapper folder named Contents. Within that you’ll see an array of folders and documents that make up the application. The execut­able code, one of the few files that doesn’t have an extension, is tucked away inside the folder named MacOS. The Resources folder contains those files that in Mac OS Classic would have been stored as resources, in the resource fork of the application file. In that are graphics and icon files for all the icons and other visual devices used by the application, text, html and other content used by various windows, and .nib documents created by Xcode’s Interface Builder; the latter are pack­aged folders and can be opened further using the Finder’s contextual menu.

Applications with multi-lingual support usually have separate .lproj folders containing localized resources for each different language version (you can produce your own custom localized version by adding such resources). Help files, DTDs, templates and defaults may also be kept here. At the top level, Info.list is a mandatory XML property list containing essential settings, including a listing of the docu­ment types handled by the application. Pkglnfo holds the old Finder informa­tion, and the Code-Signature folder supports new OS X security features.

Inside an installer package

Applications aren’t the only specialized folder types that the Finder pretends are single objects: another common subject for this trick is the installer package bearing the extension .pkg. Common delivered in .dmg disk image files, which are a single file designed to survive transmission over the internet, packages are another folder bundle with a standard prescribed layout and contents. However, some packages are now supplied as compressed archives that can’t be opened directly in the Finder without decompression.

Developers usually create them using PackageMaker, one of the utilities supplied as part of Apple’s free but vast Xcode toolkit

Packages can be inspected using the Installer’s Show Files... command in its File menu before you install the contents, but Installer lets you do little other than install or sometimes uninstall each package. Developers usually create them using PackageMaker, one of the utilities supplied as part of Apple’s free but vast Xcode toolkit. You can use PackageMaker to create your own installer packages, modify existing packages and inspect but not unbundle components within a package. If you want to install just part of a package - say, if you’ve inadvertently trashed or damaged QuickTime Player or another component only supplied within a much larger package - use Pacifist (charlessoft.com).

Like an .app, an installer package has a single wrapper folder named Contents, within which are two property lists - Info.plist and version.plist, the former containing the important settings for the package. The items to be installed are supplied in Archive.pax.gz or similar, a compressed archive that has the same folder structure as the one in which they’ll be installed on your Mac. Archive.bom is a ‘bill of materials’ listing of the contents, which will be placed in the boms folder in /Library/Receipts and form the material used for check­ing and repairing preferences. The Resources folder contains all the tools and scripts needed to run the installation within the Installer application.