Tiger UTI Encounter
Okay, so I will bore you with the story (see previous story).
I've recently begun writing shell scripts. Just little things to make my life a bit easier or pass the time. Nothing big. Nothing complicated. But over the past few months I've written quite a few scripts, and in doing so, I've developed a working method. It's really not that interesting, but what I've done when writing scripts, to keep everything organized in a way that makes sense to me, is to start with a development folder named after the script. Versions are kept here. Each time I get to a certain point in the script where something I'm trying to do is working, I'll save it with a new version number -- usually something stunningly original, like 02, or 03, or maybe even 04. I'll also label my scripts according to their level of completeness -- yellow means "not working," orange means "working but not quite the way I'd like it," green means it's "done." Finally, I've always appended these in-progress scripts with a .sh file suffix. When I have a script that I like and want to make it double-clickable, I make a copy of it, put it in a folder of useful scripts, called, shockingly, "Useful Scripts," and change its suffix to .command. The .command suffix tells Mac OSX to open the file in Terminal and run the script while the .sh files continue to open in TextEdit (now that I've assigned them to do so using the "Get Info" panel) for quick easy editing.
Or at least they did. In Panther.
Tiger, as in many of my other workflows, has made fundamental changes to the operating system that break the original functionality to some degree, and thus break my workflow. In Tiger, text files with the .command suffix open in Terminal, but so do ones with the .sh suffix. If I change the "Open With..." application for .sh to TextEdit, using "Get Info" and apply the "Change All" option, files with the .command get changed too, though the ensuing warning message still (erroneously) states that the change will only affect files with the .sh suffix. So for some reason, Tiger is now associating .sh and .command files with the same application type -- essentially seeing them as the same types of files, which, in a way, they are. But Panther didn't do this, Panther allowed me to specify which apps opened certain types of files based on their suffix. I wanted to know what was going on, so I decided to hunt around a bit.
One of the big underlying changes in Tiger is the way it classifies files, meaning, how it answers the questions "what kind of file is this," and "in what application should I open it?" These questions have have always been been problematic, and especially so since the inception of Mac OSX. Prior to OSX, in OS9 that is, the Mac used information in the resource fork of any file to determine the file type and creator (i.e. the application that should open the file). This was usually a pretty good system, in my experience. But once OSX came along, Mac started using a combination of criteria to determine the file type and creator. Resource forks were still used, but in addition to resource forks, you could use file suffixes (like .sh and .command) to distinguish your files. This added an extra level of complexity to the association (between application and file) process, but also an extra level of flexibility: I could name two identical files with different suffixes, and then associate the suffixes with various different applications. So, I could have files with the .sh suffix open in TextEdit, and then have virtually identical (in content) files with the .command suffix open in Terminal. This was pretty nifty, I must say, and I got very used to it.
Silly me.
I should have realized that Mac OSX is still very much an evolving operating system. Apple is constantly making changes to the OS, some of them disruptive to work flows, and often (though not this one, actually) arbitrary. Each new release generally involves some kind of learning -- or maybe I should say re-learning -- curve. Key commands, for example, change all the time. (I still can't for the life of me, remember the key combo to flag an email!) It can be very frustrating. I tend to get into a way of working, and sometimes the changes made in major OS revisions drive me crazy. Then again, often they are not without purpose, and, in the end, for the better. So, I take them with a grain of salt, hold my breath, and hope.
Enter UTIs.
UTI stands for Uniform Type Identifier. With UTIs Apple is again trying to redefine the method by which files are identified and classified. From what I've read in everyone's favorite (myself included) ars technica article, they're doing so in a very smart way that should yield flexible yet accurate results and methods for both software and OS designers. The problem in the current implementation is that flexibility for the user is compromised. You see, certain UTIs and their implementation are hard coded and enforced by Apple. Software developers can write and specify their own proprietary UTIs outside of Apple's set, but type identifiers lie inside applications themselves and can't really be altered by the user. This means that, at least at this point, users have no way to associate a particular kind of file with more than one application if that specification has already been made in Apple's UTIs.
You can see where this is going, right?
So after much hunting around, reading up, and deleting of preferences and caches, I discovered (using the excellent RCDefaultApp preference pane), much to my dismay, that both .sh and .command files have a UTI defined for them. And it's the same UTI. So there is no way for the user to change the application association of one without changing the other. At least not that I could find. And I tried pretty hard. This means that this sort of association decision has been largely removed from the hands of the user and placed in the hands of developers. And now there's no way to change it. At least in OS9, if you wanted to (and I often did) you could get a resource editor and change the application association of a given file. And in Panther you could do this as well, but you had the extra option of simply changing the file suffix and making the association for all similarly suffixed files the same in the Get Info panel. Now we have a system of rigidly designed and enforced (from a user standpoint) identifiers and no way to override them for our own devious purposes, or, for that matter, for our most basic of workflows. I suppose now I'm going to have to rename all my .sh files to .txt to get back my old workflow. (Can anyone say "Automator?" Or, wait, maybe I'll just write shell script to do it. Seems more ironic.) But God only knows if, when or how the UTI for .txt will change. Or if Apple will even continue to use the UTI system.
Yes, I live in constant fear.
I've recently begun writing shell scripts. Just little things to make my life a bit easier or pass the time. Nothing big. Nothing complicated. But over the past few months I've written quite a few scripts, and in doing so, I've developed a working method. It's really not that interesting, but what I've done when writing scripts, to keep everything organized in a way that makes sense to me, is to start with a development folder named after the script. Versions are kept here. Each time I get to a certain point in the script where something I'm trying to do is working, I'll save it with a new version number -- usually something stunningly original, like 02, or 03, or maybe even 04. I'll also label my scripts according to their level of completeness -- yellow means "not working," orange means "working but not quite the way I'd like it," green means it's "done." Finally, I've always appended these in-progress scripts with a .sh file suffix. When I have a script that I like and want to make it double-clickable, I make a copy of it, put it in a folder of useful scripts, called, shockingly, "Useful Scripts," and change its suffix to .command. The .command suffix tells Mac OSX to open the file in Terminal and run the script while the .sh files continue to open in TextEdit (now that I've assigned them to do so using the "Get Info" panel) for quick easy editing.
Or at least they did. In Panther.
Tiger, as in many of my other workflows, has made fundamental changes to the operating system that break the original functionality to some degree, and thus break my workflow. In Tiger, text files with the .command suffix open in Terminal, but so do ones with the .sh suffix. If I change the "Open With..." application for .sh to TextEdit, using "Get Info" and apply the "Change All" option, files with the .command get changed too, though the ensuing warning message still (erroneously) states that the change will only affect files with the .sh suffix. So for some reason, Tiger is now associating .sh and .command files with the same application type -- essentially seeing them as the same types of files, which, in a way, they are. But Panther didn't do this, Panther allowed me to specify which apps opened certain types of files based on their suffix. I wanted to know what was going on, so I decided to hunt around a bit.
One of the big underlying changes in Tiger is the way it classifies files, meaning, how it answers the questions "what kind of file is this," and "in what application should I open it?" These questions have have always been been problematic, and especially so since the inception of Mac OSX. Prior to OSX, in OS9 that is, the Mac used information in the resource fork of any file to determine the file type and creator (i.e. the application that should open the file). This was usually a pretty good system, in my experience. But once OSX came along, Mac started using a combination of criteria to determine the file type and creator. Resource forks were still used, but in addition to resource forks, you could use file suffixes (like .sh and .command) to distinguish your files. This added an extra level of complexity to the association (between application and file) process, but also an extra level of flexibility: I could name two identical files with different suffixes, and then associate the suffixes with various different applications. So, I could have files with the .sh suffix open in TextEdit, and then have virtually identical (in content) files with the .command suffix open in Terminal. This was pretty nifty, I must say, and I got very used to it.
Silly me.
I should have realized that Mac OSX is still very much an evolving operating system. Apple is constantly making changes to the OS, some of them disruptive to work flows, and often (though not this one, actually) arbitrary. Each new release generally involves some kind of learning -- or maybe I should say re-learning -- curve. Key commands, for example, change all the time. (I still can't for the life of me, remember the key combo to flag an email!) It can be very frustrating. I tend to get into a way of working, and sometimes the changes made in major OS revisions drive me crazy. Then again, often they are not without purpose, and, in the end, for the better. So, I take them with a grain of salt, hold my breath, and hope.
Enter UTIs.
UTI stands for Uniform Type Identifier. With UTIs Apple is again trying to redefine the method by which files are identified and classified. From what I've read in everyone's favorite (myself included) ars technica article, they're doing so in a very smart way that should yield flexible yet accurate results and methods for both software and OS designers. The problem in the current implementation is that flexibility for the user is compromised. You see, certain UTIs and their implementation are hard coded and enforced by Apple. Software developers can write and specify their own proprietary UTIs outside of Apple's set, but type identifiers lie inside applications themselves and can't really be altered by the user. This means that, at least at this point, users have no way to associate a particular kind of file with more than one application if that specification has already been made in Apple's UTIs.
You can see where this is going, right?
So after much hunting around, reading up, and deleting of preferences and caches, I discovered (using the excellent RCDefaultApp preference pane), much to my dismay, that both .sh and .command files have a UTI defined for them. And it's the same UTI. So there is no way for the user to change the application association of one without changing the other. At least not that I could find. And I tried pretty hard. This means that this sort of association decision has been largely removed from the hands of the user and placed in the hands of developers. And now there's no way to change it. At least in OS9, if you wanted to (and I often did) you could get a resource editor and change the application association of a given file. And in Panther you could do this as well, but you had the extra option of simply changing the file suffix and making the association for all similarly suffixed files the same in the Get Info panel. Now we have a system of rigidly designed and enforced (from a user standpoint) identifiers and no way to override them for our own devious purposes, or, for that matter, for our most basic of workflows. I suppose now I'm going to have to rename all my .sh files to .txt to get back my old workflow. (Can anyone say "Automator?" Or, wait, maybe I'll just write shell script to do it. Seems more ironic.) But God only knows if, when or how the UTI for .txt will change. Or if Apple will even continue to use the UTI system.
Yes, I live in constant fear.
Labels: MacOSX, Systems, Tiger
This entry was posted
on Sunday, May 29, 2005 at 1:53 PM.
You can skip to the end and leave a response.
» Post a Comment