I have a script that won’t load so I was thrilled to discover that Script Debugger 6 has a “Recover Damaged Script” feature.
Unfortunately, when I open File - Recover Damaged Script I am not able to select anything except in the Finder Sidebar, all selections in the right panel are “greyed out”.
This appears to be some kind of bug. When I drag the folder containing my script to Finder Favorites, I am then able to select the folder and select the script in the right pane.
This is not convenient. I can understand greying out files that are not SCPT files, but one should still be able to select folders to “drill down” to where scripts are located.
Yes, it would seem to be a bug. Unfortunately, Script Debugger 6.0.1 just shipped today so a fix will have to wait for 6.0.2.
You can work around this problem by dragging the folder you want to access from the finder into the open panel Script Debugger presents to take you to the desired location where you can pick the script to recover.
I have Script Debugger 6.0.4. One of my scripts appears to be damaged. When I attempt to use Recover Damaged Script I find that the file is grayed out, although other SCPT files in the folder are not. Is this a known problem? Is there any way to get at the script? I have a recent printout, so I suppose I can retype 100 lines if I have to.
If you can select your script in Finder then either hit the space bar or type command-shift-P, and your script comes up in Finder you might be able to recover it. I recovered a damaged script today using a special way after Recover Damaged Script didn’t work. You could upload your file & i can try. If it works I can post or upload it. The method involves extracting an RTF resource
Thank you for the generous offer of an alternate recovery method. I have been able to use a recent .applescript file and have since recovered everything lost. So, I deleted the damaged file.
If that happens again the basic idea behind recovering the file is this:
There are things stored in the script called resources. The resources have types like 'RTF ’ (which is a Rich Text Format) and ‘TEXT’. The resources also have names like 02001"Source Text".txt which is of type ‘TEXT’ and 02000 “QuickLook Preview” which is of type 'RTF ’
The 02001"Source Text".txt is a back up copy of the script that is used in trying to recover damaged scripts. The 02000 “QuickLook Preview” is used to show a quick non-editable look from Finder of what is in the file. If restoring from 02001"Source Text".txt doesn’t work (this is the resource used when selecting “Recover Damaged Script” from the menu) then the the information in the *02000 “QuickLook Preview” can be used to get the text. While the text in the"QuickLook Preview" resource is stored in rich text format it can still be pasted into a Script Debugger script window. The formatting in the resource is stripped away and Script Debugger uses only the text pasted into the document.
The only trick to this is having a utility to extract the resources from the script. This was why I offered to to try and extract it. I used an app called “rezycle” from the app store. But that costs something like $5. To use the app you just open it, then drag and drop the script file on the window that opened in rezycle. rezycle creates a folder that contains a copy of all the resources in the script. The created folder in placed is the same folder as the script file. You just go into the folder and select whichever resource you want to see and double click. Or you can just ask me if that is too technical or too expensive.
Thanks again for this detailed description of an alternate recovery method. I think if it happens to me again, $5 for a resource editor will be well worth the price. Your explanation is clear enough that I will post it in my “Program Gotchas” folder, where I keep solutions to rare, tricky problems.
I have been thinking about making that a feature request. The only problem is that many things that would wipe out the “Source Text” backup would also wipe out the “QuickLook Preview” resource as well. But as I am finding out there are times where the “Source Text” does get wiped out while the “QuickLook Preview” does not. To me I would want to try every possible way to recover a script. But I can’t say just how many times the original and “Source Text” would be wiped out but the “QuickLook Preview” would survive. So I keep thinking maybe I should ask that for a feature request.
What it comes down to is there are multiple alternatives. Is it better is to hang onto the old source code that was being used before a save as well as the the source text that was actually saved. This helps when a script dies on me and later I go to get it from the script file but it turns out the problem existed before I saved and what was saved was also messed up. Then the “Recover Damaged Script” has a backup and another backup before that.
So this method would be something like move “Source Text” into “Source Text backup,” put the text about to be saved into “Source Text” and then save the information to the disk. Both “Source Text” and “Source Text backup” would be saved in a resource in the script file.
Of course Script Debugger could have a problem that would make all future saves go wrong until it is restarted and this would not work. It has been my experience that in nearly all cases either the file is empty or correct. But you could have yet another backup but it would have to end somewhere. Also Script Debugger could read what it just wrote to disk and compare it to what is in the editor right after that save. So there are a lot of alternatives with some that return moderate gain but would be easy to do, while others return better results but would be harder to do.
Another that could be done is to check the size of what was saved and if it is a zero byte script then issue a warning and to users and they can act accordingly. I would expect it would be a pretty small number of users, if any at all, that would save a blank file on purpose.
So if I asked for a feature request I’m not sure what to ask for. But for right now the method I described does work if the “Quick Look” is still intacted and someone wants to do the manual work themselves. Apparently I’m not very good at being decisive on this issue .
Yes. The problem is in knowing when or where something has gone wrong. In Bill’s case, the text resource is present and valid – it just doesn’t contain what’s expected.
We need to determine why the Source Text resource is messing/empty. That is the core issue. Lets not run off thinking of workarounds when we can simple fix whatever is wrong in SD. This is the first time I’ve heard of this particular type of failure in Script Debugger. I’m hoping that there is an explanation for it all and perhaps a fix we can deliver.
I am pretty sure I have never forgot to quit “UI Browser” before I started to work with Script Debugger and I have heard of it crashing an application it was scanning. Perhaps “UI Browser” crashed safari and safari corrupted something that interfered with Script Debugger. At the time “UI Browser” was targeting Safari while I was working on scripting Safari but I was not doing anything more with “UI Browser.” But "UI Browser"might had had some kind of scanning still going on.
I can’t reproduce the problem with leaving “UI Browser” on and scripting safari while working with Script Debugger so it is really hard to tell how much of a problem “UI Browser” caused. I’m sure they hacked a lot of stuff to get that to work. I did have 8 applications running at the time but I do have 64 gigabytes of memory. The only App that was doing anything was Script Debugger and maybe “UI Browser” did something. The rest of the apps were idle. I do remember there was one strange thing sent to the console at the same time.
The best I can say is Script Debugger seemed to be working find but as soon as the save began the spinning beach ball appeared and when the beach ball disappeared the text vanished from the document window. I used Script Debugger after that and it had no further problems even with “UI Browser” running although now that I think of it I didn’t have the browser targeted to any particular application so maybe that wasn’t a very good test. I can try it again with it targeted to safari.
The oddest thing is before and after the text vanished Script Debugger seemed to work fine. I didn’t have to quit SD to get it to work again. I assume the spinning because ball was caused by something that hung SD up and it is possible “UI Browser” did something with Safari at that time. But that in itself shouldn’t make text vanish from the document window or from the saved file. I am open to any kind of test you can think of to try and reproduce the problem.
When you said the resource was still there and valid I assumed you meant the resource was present and not corrupted. But then I got to wondering if you meant the script text was in the text resource in the file I saved to disk. The 02001 “Source Text” ‘TEXT’ resource was empty when I check it on my Mac.
That’s correct. As long as the resource is there, even if it’s an empty string, when opening it what’s to say that’s not what the script contained? Thus Mark’s point.
.