|
|
|
|
||
        |
|
 |
|||||||||||||||||||||||||
 |
 |
|||||||||||||||||||||||||
|
Playing Detective -- Finding Out Why My Mac is Crashing Have you had problems with your Mac lately and been unable to track down the problem? Plagued by system crashes? Can't afford to go get Conflict Catcher, but know a little AppleScript? We all have computer problems from time to time, and I'm no exception. I've reloaded Mac OS 9.1 twice in the last month, because I began to experience problems with AppleScript, of all things! Every time I tried to save or check syntax on a script, the system would freeze and become totally inoperative. Other symptoms included the Extension Manager crashing whenever it was started and bold face menu titles. So I set out to track the crashes, by writing a couple of log file scripts. The principle is simple, put an AppleScript in the startup Items folder that logs the date and time each time the system is started. Put a similar script in the Shutdown Items folder that logs each proper shutdown. If you wind up with two startup entries in a row, then you know that the system crashed. Granted, this is not a substitute for Conflict Catcher (or any other utility) but sometimes simple approaches like this can yield enough information for you to at least know where to look. If you look at the Standard Additions dictionary, you will find commands for opening, reading, writing, and closing text files. These, plus the try...on error...end try block are all you need to get started with simple text files. First, let's create a file path for our log file. The open for access command needs a reference to a file, and the best place to put a log file is the System folder. So we begin like this: copy (((path to system folder) as text) & "startup log") to FilePath The result of a path to statement is a file alias, but in this case, we want to add "startup log" to the path, so we convert the file alias to a plain text string using the as text phrase. This is called a coercion because we are coercing an expression of one type to a different (but compatible) type. What is a "compatible type?" Well, for example, you could cast a path to a text string, but you can't coerce a text string to a file alias if the file doesn't exist yet because an alias must always point to a real file. Now, in order to protect ourselves against errors, we surround the next few statements in a try block. That way, if anything goes wrong, the on error routine will be executed: try The dictionary entry for the open for access command is printed below. As you can see, it returns a result that is an integer reference to the file. You can use this as a "handle" to the file and use it to refer to the file in the rest of the file handling commands. For that reason, we copy the result to a variable for later use. We use the write permission clause because we need to write to the file. If we were just reading from it, we would not need it.
Next, we write our log entry, using the current date command (coercing it to a text string) followed by a carriage return. We tell AppleScript to start writing the entry at the first character after the end of file (eof) marker so we don't overwrite previous entries.
The on error part of the try block can return different kinds of information, but in this case, we just want the text of any error message returned so that we can display the error in a dialog box. Finally, we close the file using the close access command:
Wrapping It Up The last statement closes the file. We put it outside the try block so that it will attempt to close the file whether there is an error or not. A file left open because of an error after the open for access statement could cause us problems, so we make sure that the script attempts to close the file no matter what. The entire script is pictured below. As you might guess, the Shutdown script is identical to the Startup script with the exception that we change the write statement to reflect a shutdown event rather than a startup.
Now, if you have been reading this column for a while, you will notice that something is missing from our script. It has no tell...end tell block! Because you are not telling the Finder or any other application what to do, it is not needed. We then put the two scripts in their proper folders and let them do their work, tracking startups and shutdowns. When you inspect the log file, and find a crash event (two startups in a row), you can use Sherlock to find out what files were changed around that time period, giving you some information about what was going on at the time. Have I figured out what's going on with my Mac? Not yet, but give me time...
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:
|
||||||||||||||||||||||||||
|
 |
|||||||||||||||||||||||||
