If you are learning AppleScript there are some things you should know when working with file extensions. First of all, there is no file extension, Mac OS X is built on top of the virtual file system named UNIX File System (UFS). UFS doesn’t support extensions like MS-DOS file system does, only allows one and long file name. That means that the file extension and file name are something that virtually shown by the Finder to the user using Mac OS X’s own file manager. That includes that the same script running on a different system could give you different results, which would not be possible if file extensions were actually part of the file system.
Rename any file so it has an extension name “1” (or another file extension that is not supported by the Finder). Well now it’s getting interested. When using Stefan’s code using the Finder it will tell you it has no extension. Getting properties of a file using System Events, which is Apple’s suggested successor to the deprecated info forcommand. As promised the file properties are pretty much like info for which mean that the file with the extension “1” is considered an valid extension by System Events. Aren’t the Finder and System Events using the same file manager and file system? No, like mentioned before there is no extension in the file system itself, The Finder and System Events seems to have their own implementation on determining the extension of a file. The Finder will look if it supports the extension while system events does not.
When a file has an extension “1” System Events will return the file extension “1”
separateNameExt(choose file)
on separateNameExt(theFile)
tell application "System Events" to set {name:fileName, name extension:fileExtension} to theFile
if fileExtension is in {missing value, ""} then return {fileName, ""}
return {text 1 thru ((count fileName) - (count fileExtension) - 1) of fileName, fileExtension}
end separateNameExt
When a file has an extension “1” the Finder will return no extension
separateNameExt(choose folder)
on separateNameExt(theFile)
tell application "Finder" to set {name:fileName, name extension:fileExtension} to theFile
if fileExtension is in {missing value, ""} then return {fileName, ""}
return {text 1 thru ((count fileName) - (count fileExtension) - 1) of fileName, fileExtension}
end separateNameExt
The same results as system events but faster and plain AppleScript:
separateNameExt("noextension") -- result: {"noextension", missing value}
separateNameExt("standardextension.txt") -- result: {"standardextension", "txt"}
separateNameExt("com.bundle.name.1") -- result: {"com.bundle.name", "1"}
on separateNameExt(fileName)
if fileName does not contain "." then return {fileName, missing value}
set oldTIDs to AppleScript's text item delimiters
set AppleScript's text item delimiters to "."
set fnm to text items 1 thru -2 of fileName as string
set ext to text item -1 of fileName
set AppleScript's text item delimiters to oldTIDs
return {fnm, ext}
end separateNameExt
Another drawback, which is more of a general problem, is that the Finder doesn’t look if the file is actually the right type. When I change the extension in the Finder of a file into jpeg (which was txt) the Finder will handle the file as JPEG and becomes “corrupted”. Both System Events and Finder will consider the file to be JPEG. When you use UNIX’s method to determine a file type, which is not based by it’s extension but based on MAGIC numbers and contents, the file type remains a text file and won’t be considered a JPEG format. Keep this in mind when you ever consider to work with both worlds the file type in unix can be completely different from the file type in the Finder. Because unix file type is based on content and finder file type seems to be based solely on the extension.
Why am I saying all this? Well you may experience in the future different results from different ways of scripting using different file systems but also between different OS. I wanted to give you some head start. All these issues comes from the fact that HFS+ should not have been implemented in Mac OS X. Or at least the Finder shouldn’t use any HFS+ specific features but only UFS features. That is because everything goes through UFS and nothing is written directly to the HFS+ file system. So UFS is tweaked in a such a way that the actual data stored on an HFS+ file system is very ugly. Or as Linus Torvalds said “utter crap which makes it a scary file system”.