I thought this was fixed. If I option click on a script in the TextWrangler script menu, it opens in Script Debugger as an untitled script. So save it I have to navigate deep within the TW bowels to reach the scripts folder.
This happened before and then stopped happening, now it’s happening again.
–>Script Debugger 6.0.1 (6A180) on OSX 10.10.4
This isn’t really a Script Debugger bug. Your document is configured to be a stationary pad and so the system creates a copy of the document each time it is opened for editing. You can change this by unchecking the Stationary Pad option in the file’s Finder Get Info panel:
That’s not it. The script does not have that box checked. Nor was that checked when that happened in previous versions.
Ed,
The last sample you sent had the stationery bit set. Can you open the script, copy and paste into a new document, and tell us if the new document exhibits the same behavior?
No, it opens as with the correct name.
I have about 50 scripts in the Text Wrangler Scripts folder.
Only a few have this issue.
05)NewsGateNoteOut.scpt
05)Quote&Parens.scpt
22)SeparateTags.scpt
26)HTML-WithBlockQuote.scpt
27)WrapWithStrong.scpt
50)PrepParagraphsForP2P.scpt
One file has the problem intermittently. It will open with its name sometimes and as untitled other times.
27)WrapWithBlockQuote.scpt
I’ve verified that the stationary button is not checked on all of them in the finder. (They also open as untitled if I open them from the finder, so it’s not the TW scripting interface).
Here’s a link to the problem files.
If I remember correctly, your previous problem file had an old System 8 stationery flag set. I suspect it’s the same issue, and the only practical solution is to make new versions without the flag set.
So looking at these scripts, they have all been modified fairly recently. The most recent Aug. 1. The least recent in Nov.
They have only been edited and saved in SD. And I am certain they didn’t have this issue. The problem seems to have gone away, and now it’s back.
All but one of the scripts you’ve posted to Dropbox show a size of 0 bytes. And unless you put them in an archive, the problematic resource-fork stuff may be removed by Dropbox anyway.
Not sure if this is relevant, but the way I make new scripts for a script folder is by going to the finder and duplicating a script, then either rename and open the copy or open and edit the copy and rename while saving or after saving.
It looks like all of these were based on the same script (because the preview for all of these is the same.)
In each of these cases the scripts would have been opened and saved in SD.
If you keep doing that, you’re going to keep having the problem.
You’ve started with a very old file that has a System 8 bit set that is no longer generally accessible. However, SD recognizes it as part of its goal to faithfully read all old file formats. Quicklook too is looking at the old preview.
This is a case of “Doctor, doctor, it hurts when I do this.” The answer is to throw that file away and start with a newly saved one.
That’s fair enough. Only thing is it seemed that the solution that used to work (opening the file in SD and saving it again) doesn’t work anymore.
I’m tempted to try to find what’s changed, but I’m not sure at what point it happened. And given that what it’s doing now is honoring the setting rather than ignoring it, I’m not sure that making a change would be sensible.
Script Debugger 5 tried to preserve file type and creator codes along with Finder flags when saving documents. All of this was removed from Script Debugger 6 as we finally abandoned file type and creator codes in favour of file name extensions… I believe there are two mechanisms for stationary pads: Classic Finder flags that ride with the file and whatever Mac OS X does which seems to be separate from the file, possibly maintained in the LaunchServices data store.
You can try saving your revised script under a new name, delete the existing file and then move/rename the new file to take the old files place using the Finder. This may get the stationary pad information to be fully reset.
Another option is to use the SetInfo command line tool to remove the stationary pad flag from your files. Sorry, but I cannot seem to find the SetInfo man page anywhere on apple’s web site.
I’m going to write a droplet that will open scripts dropped on it, if any open as untitled it will trash the original, copy the text to a new script and save that in the original’s place.
The thing I don’t get is that these scripts had all been opened and saved in SD6 fairly recently.
It seems that SD was ignoring the setting, but preserving the setting, and in one of the recent versions stopped ignoring the setting.
tell application "Script Debugger"
set thisDoc to open ThisScript
end tell
On these scripts that have the hidden stationery setting, when I run this script (as part of a droplet, where thisScript is an alias), the problem script opens as an untitled script, but the variable thisDoc is missing value. Shouldn’t it return a reference to the “Untitled” window or tab that opened?
Also, in running this in SD, it seems the applications gets easily confused between which tabs and windows to display. If I can recreate I’ll send a full bug report, but the behavior I was seeing was after opening and closing several scripts via scripting, only one script window and no tabs would be visible in SD, but when I tried to close the window, I’d get an alert that there were two scripts with unsaved changes.
There was no tab bar showing, not other files in the Windows menu. My only choice was to close the window and continue when the alert displayed. There was no way to see the window/tab with the unsaved changes.
When I try this code I get a document reference back:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
set theFile to choose file
tell application "Script Debugger"
set theDocument to open theFile
end tell
I suppose the presence of the stationary pad bit may be messing things up.
Hey Ed,
If your problematic .scpt scripts were created with Script Debugger then use the Satimage.osax to read the backup text resource, and see if you can avoid the problems you’ve been having.
--------------------------------------------------------------------------------
# Extract Script Text from Old-Style .scpt Files Created with Script Debugger
# REQUIRES the Satimage.osax → http://tinyurl.com/dc3soh
--------------------------------------------------------------------------------
set scriptFile to alias ((path to downloads folder as text) & "Test Script.scpt")
set scriptSource to load resource 2001 ¬
type "TEXT" from scriptFile ¬
as «class utf8»
tell application "Script Debugger"
make new document with properties {source text:scriptSource}
end tell
--------------------------------------------------------------------------------
-Chris
Thanks, Chris, but I’m not sure that would help. Since the preview for each script is from the old script that was opened and then reserved, I think that’s what I would get here. (I don’t have that Osax on this machine, so I can’t test).
But I’ve solved the problem I was having.
But, I want to make sure that the bug part of this thread doesn’t fall through the cracks.
When one of these scripts is opened in SD from a script, you don’t get an appleEvent result.
set openedScript to open anyScriptWithThisIssue
The variable openedScript has no value.
Also, early on Mark suggested that the problem was that the stationary pad box was checked in the Finder and that was causing the problem.
Turns out that SD seems to ignore that setting. I can open, modify and save scripts with that setting with no issues. (If the file is locked, that’s different.)