|
|
|
|
||
        |
|
 |
|||||||||||||||||||||||||||||||
 |
 |
|||||||||||||||||||||||||||||||
|
Supporting Multiple Users One of the more useful (but not perfect) changes in Mac OS 9 was the addition of support for multiple users. This is a feature that Windows has had for a long time, and it was long overdue for the Mac OS. Now you can have several users on a single machine, each with their own preferences and desktop settings, their own file storage area, etc. They can even customize the Apple Menu to their own taste, adding and removing aliases to programs, and documents they use frequently or not at all. One of the reasons that this new arrangement is less than perfect is because older programs (even Applescripts) don't know about the addition of the Users folder on the startup drive, much less the other, more specialized folders within each user's folder. Most programs look for those folders in the System folder, where they always used to reside, and still do, for the owner account. As anyone who has used a Mac prior to OS 9 knows, the System folder contains the Apple Menu Items folder, the Preferences folder, and other, more arcane stuff. And if you do not enable the Multiple Users control panel, those folders continue to function the way they always have.
Down the Garden Path... But the folks at Apple realized a long time ago that not all of us leave our hard drives named "Macintosh HD" or use the same disk to startup each time. For that reason, they built into Applescript's Standard Additions dictionary the path to statement. For certain, key folders you can get the complete path to the folder by referencing it like this:
What you get back is an alias to that contains the entire path to that object. Remember, In Applescript, an alias is a pointer to a file or folder, not the actual item itself. The complete list of supported paths (as of OS 9) is:
Those of us who have been writing programs to run on Apple computers (both the old Apple //'s and the Mac) know that Apple has always advocated and supported indirection to allow "wedging" things into the OS when it was necessary. Smart programmers have used the indirect method of referring to things rather than going directly to the hardware (or the disk structure) to prevent one program from stepping on another. Example: If you patched the old Apple // keyboard input routine, you left the address to your routine at a known (published by Apple) address to allow other programs to continue functioning as if you had never patched the original routine. Without this indirect method, other programs would have gone directly to the hardware or the original input routine, bypassing your patch, effectively "cutting you out of the loop." The path to statement serves much the same purpose. If your scripts always access the items listed above using it, then you will always find the object you are looking for, no matter where it gets moved to in future releases of the OS. With the addition of Multiple Users and the dawn of OS X, this is becoming more and more important! While your mega-kewl script that does whatever may work on your Mac (whose hard drive is called "My big, fat, hard drive") with a hard-coded path embedded in it, it will break the moment you distribute it to someone else, and your script (and your reputation) falls flat on its face.
Follow Me! OK, so we have established that the path to statement is important. Here's an example of what you can do with it:
If you save this script as a compiled script, you can stick it in your OSA Menu in the Finder Scripts folder, and you can add items to the Apple Menu by selecting them and invoking the script. If you save this script as a classic applet, you can drop it in your "Speakable Items" folder and use it with Speech Recognition. And the bonus is that this script will work with Multiple Users turned on! Any user, from the owner on down can use this script and it will work for them, without you having to explicitly name a path! You can even give this script to your friends, publish it on your web site, and it will work for anyone!
Another Example If you have ever tried troubleshooting startup conflicts on your Mac, you know that items in the Startup Items folder launching every time you restart can be a pain. Rather than digging through the System folder or the Users folder looking for the offending items, why not put Applescript to work and let it disable them? Here's the script:
Except for the path to statement, there really isn't anything new in these scripts. But boy, are they helpful! I will leave it as an exercise for the reader to write other useful scripts, but here are some suggestions:
And here's an extra challenge: Write a script to get the user's folder names from the Users folder and give the owner account an Applescript that puts an alias in each user's Apple Menu (or on their Desktop, or their Startup Items, etc.)! User management made easy! In closing, here are some useful scripts from Apple. There are scripts here to add prefixes and suffixes to file and folder names, lock and unlock files, set file type or creator codes, some QuickTime scripts, some OS X Beta scripts, etc. Most of them require some version of OS 8 or higher.
More About the AppleScript Foundry Every month in the AppleScript Foundry, I'll be sharing what I know about scripting. Since the object of this column is to get people who are new to scripting up and running, I will take a hands on approach, explaining new terms along the way. However, it is not my goal to talk down to the reader - If you want harder stuff, just write me! You can reach me at kevin@macosjournal.com or you can use the handy web feedback form. Here is a list of places you can go to get more info on AppleScript:
|
||||||||||||||||||||||||||||||||
|
 |
|||||||||||||||||||||||||||||||
|
