I have a workflow, that downloads files from an FTP to my computer, using transmit and automator.
The action in automator looks like this:
The information for this action is correct, and the files of the remote file path are downloaded to my computer.
However, a 1/3rd of the way through the download (~200 files), automator throws an error:
The download still continues, but the error stops automator from doing the rest of the workflow.
So my question is:
How can I solve this error, or at least make the workflow continue after the error is displayed?
There is a way to have Automator continue on with the workflow without timing out. With AppleScript, If you wrap the download command within a with timeout of 1000 command (1000 is in seconds. Use whatever number you think will work), the script will now wait for up to 1000 seconds for the download command to complete, instead of the default of 120 seconds, before timing out or moving on to its next command.
So instead of adding the Automator Transmit Download action to your Automator Workflow, you can insert a Run AppleScript command to your Workflow
For example let's say you want to download every currently selected file on the remote browser of the current tab in Transmit.app without timimg out, you would insert a Run AppleScript command to your Workflow and insert this following AppleScript code. (obviously editing the properties in the code to suit your needs.)
property downloadLocation : POSIX path of (path to desktop)
property filesToDownload : missing value
tell application "Transmit"
tell its document "Transmit"
set selectedFiles to a reference to selected browser items of ¬
(get remote browser of current tab)
if (count of selectedFiles) > 0 then
set filesToDownload to path of selectedFiles
else
return
end if
repeat with thisFile in filesToDownload
with timeout of 1200 seconds
download remote browser of current tab item at path thisFile to ¬
downloadLocation with resume mode resume
end timeout
end repeat
end tell
end tell
This is from Panic's library:
When configuring Automator to Upload or Sync large files, Automator
can experience an error: “The action “Synchronize” encountered an
error: “The operation couldn’t be completed. (Cocoa error -1)”. We’ve
also seen this error present as: -1712, -1753, and -1. -1 being the
most common.
Unfortunately, Apple has instituted a 2-minute timeout for Automator
actions for macOS versions 10.14 and above. We’ve reported this to
Apple, but at this time, there is not a fix or workaround.
If this sounds like the issue you're facing (you don't mention your version of OS or Transmit) then maybe you can adapt the workflow to process the list of files in chunks.
Related
I have an application and I can do the following command on (I know this because I googled for it):
tell app "TextMate" to reload bundles
What I would really like is to be able to ask the "TextMate" program:
tell app "TextMate" to list all commands
and have it list out all the things I can ask it to do:
... 'reload bundles', 'exit', 'open files'...
is there a way to do that with applescript?
The way to find all the commands of an app is to open its dictionary in your script editor. Usually "Open Dictionary ... " in the File menu, or drop the application onto the script editor.
[EDIT]
For applications that have AppleScript support, you can actually script opening the app itself with the Script Editor, a la:
set pathToApp to (choose file of type "APPL")
tell application "Script Editor"
open pathToApp
end tell
BUT this will be problematic with a non-scriptable app. You'll get an error, but Script Editor will actually open some part of the app (and it will be slow about it), then give you an unusable document. There's no way to catch this error. If you use the Smile script editor, you can use this method ...
set p to (choose file of type "APPL")
try
OpenDictionary(alias (p as string))
on error e
end try
... to open the dictionary of an app, and if it doesn't work (if the app doesn't have a dictionary), it returns an error but doesn't do anything else (but again, you can't catch the error and not have it complain, without hacking Smile)
[EDIT 2]
A rabbit hole to go down is trying System Events or the Finder to check for boolean of has scripting terminology property of a process, but I don't recommend it because I haven't found it to be reliable.
[EDIT 3]
Ach! I knew there was another method, but forgot what it was. As #mklement0 points out (thank you), you can do this to check for an app's script-ability prior to opening the app in Script Editor:
set pathToApp to (choose file of type "APPL") as text
set isScriptable to false
try
class of application pathToApp
-- only AppleScriptable applications have a class property
set isScriptable to true
end try
isScriptable
I'd like to write an AppleScript program to do the following (Automator would be fine too):
I want to open the current active TextMate file (possibly there are several tabs open and other windows) with the application Transmit 2. (This will upload the file over FTP using Transmit's DockSend feature.)
Here I've used a specific application (TextMate) but ideally I'd like it to work for any file currently active in any application.
Ultimately I will assign a keyboard shortcut to run it.
Here's what I have so far:
tell application (path to frontmost application as text)
set p to path of document 1
end tell
tell application "Finder"
open POSIX file p using "Transmit 2"
end tell
I've tried many variants of this and nothing works.
EDIT:
I have found this page: http://wiki.macromates.com/Main/Howtos and someone has made exactly the script I'm looking for:
tell application "Transmit" to open POSIX file "$TM_FILEPATH"
This is for Transmit [not 2] and I think for TextMate pre v2. I get the error (when using Transmit 2):
Transmit 2 got an error: AppleEvent handler failed.
One of the updates to v2 has broken it (not sure which one).
There appear to be two steps to your problem. One, get the path to the document (or some other reference that allows you to later open the document), and, two, open the document in the desired application.
If the AppleScript is saved as an application, the frontmost application is the AppleScript you’re running, and so that path will be the path to the AppleScript application. In that case, I’m not aware of how to get the second-frontmost application.
However, if the application supports the scripts folder (go into AppleScript Editor‘s preferences, and enable “Show Script menu in menu bar”), you can save the script as a “Script“ in the User Scripts folder, and when run from the scripts menu the frontmost application will be the application you’re currently in.
You may want to display the p variable when testing to ensure that you are getting the correct path and not the path to the AppleScript.
As far as opening the document in another application (such as Transmit), the best way to do this is to talk to the application directly if it supports it:
tell application (path to frontmost application as text)
set p to path of document 1
end tell
--for testing: verify that the path is for the correct document
display dialog p
tell application "Transmit 2"
open p
end tell
I don’t have Transmit, but I’ve verified that this works if I replace “Transmit 2” with Textastic or Smultron 6.
If you do need to use the Finder to open the document, the Finder seems to prefer its paths as strings, and also seems to prefer a full path to the application. Something like this should work:
tell application (path to frontmost application as text)
set p to path of document 1
end tell
--for testing: verify that the path is for the correct document
--display dialog p
set transmitPath to path to application "Transmit 2"
set p to POSIX file p as string
tell application "Finder"
open file p using transmitPath
end tell
Again, I’ve tested this using Textastic and Smultron as the applications.
The most common solution for the problem you are trying to solve is to run an app that makes your Web server appear to be a mounted Mac disk. Transmit 4 has that feature, which Panic calls “Transmit Disk.” But there are a few other apps also — Transmit was not the first.
Your Mac apps (and AppleScripts) just see a typical Mac disk that they can save files to and read files from (the most basic of basic AppleScript tasks) and yet Transmit Disk (or similar app) is transparently mirroring any changes to that Mac disk to your Web server in the background. This makes all the network and FTP stuff totally go away and leaves you writing very simple scripts that do very powerful things to your Web server. You Save HTML documents on there, you Export image and movie files onto there as easily as you would Save them on your Desktop, and yet they are immediately published to your Web server. Even the only barely scriptable apps can Save their files onto a particular disk.
For example, if I have an HTML document open in BBEdit and I want to save a copy of that document to my Web server, it only takes a few lines of code, which would likely be similar in any AppleScript-able text editor (this script would also work verbatim in the free TextWrangler):
tell application "BBEdit"
set theHTMLSource to the contents of text window 1
make new document with properties {text:theHTMLSource}
save document 1 to file "Transmit Disk:index.html"
close document 1 saving no
end tell
Notice that the AppleScript above not only doesn’t have to know anything about SFTP or have any login credentials, it doesn’t even have to figure out the file path of my current document because it just takes the content right out of the current window. There are no POSIX pathnames, no shell scripts, no monkey business at all. And because this task and code is so simple, you could conceivably rewrite this script 20 times for 20 different apps that you may use, so that they can all Save a copy of their current document onto your Transmit Disk, and thus publish that document to your Web server.
And if I have a folder of images that goes along with that HTML document, I can ask Finder to duplicate that folder onto my Transmit Disk to publish it. With just one line of code:
tell application "Finder"
duplicate folder "images" of (the path to the desktop folder as alias) to the disk "Transmit Disk" replacing no
end tell
… but those images could also be exported out of Photoshop or any app, right onto the Transmit Disk, via AppleScript.
In short, the thing that all of your Mac apps have in common is they can all Save files to a Mac disk. They can’t necessarily all give you the pathnames to the documents they have open, or open those files with Transmit. And Mac apps and AppleScript were designed primarily to work with files Saved or Opened to/from local disks. So you gain a lot if you use something like Transmit Disk to make your Web server basically part of the AppleScript party, by making it appear to be just a plain old Mac disk.
I'm trying to make two copies of an AppleScript, one that works for Entourage and one for out Outlook. I only have Entourage installed on the current computer.
According to the info on Microsoft's site, both applications have the same library of AppleScript commands, and I should be able to simply change the application name referenced within the script.
Changing:
Tell application "Microsoft Entourage"
to
Tell application "Microsoft Outlook"
Prevents me from saving the script because I don't have outlook installed on this computer. Is there any way around this? Do I need to use a text editor to edit the actual script file and change it there?
Thanks!
The following work-around may do the trick. On the computer where Entourage is installed, a using terms directive will let you compile the script, even if Outlook is not installed:
set theApp to a reference to application "Microsoft Outlook"
using terms from application "Microsoft Entourage"
tell theApp
get version
...
end tell
end using terms from
Upon compiling and saving the script the AppleScript Editor will bug you about the missing Outlook application, but it will nevertheless produce a compiled AppleScript file (.scpt).
Applescript is a pre-complied file format, meaning that every time you click "Save" it runs through a series of steps to ensure the script will work, but just short of actually running through the script's logic. Part of those steps is to look for the application to see if it exists on the Mac.
In short, if you want to save the script as an Applescript, you need the target application installed, otherwise you can save the script as a text file and move the file over to the target Mac to save as an Applescript over there.
It should be possible to make one script that works with both Entourage and Outlook, without bugging you if one isn't found either when you compile or when you run. I don't have either Entourage or Outlook but it should work like this:
using terms from application "Microsoft Entourage"
script theScript
tell application "Finder" to try
set theApp to application file id "Entourage's Bundle ID" as text
on error
set theApp to application file id "Outlook's Bundle ID" as text
end try
tell application theApp
-- do stuff
end tell
end script
end using terms from
store script theScript in "MyScript.scpt"
"using terms from" is only relevant when compiling the script - it isn't needed when running, though for some reason you'll still get bugged if that app isn't found. So by wrapping it around a script object and then writing out that script to file, the resultant script will still run but won't contain "using terms from" and so won't bug the user.
For getting a reference to the right app, Finder can look for it by ID and simply error if it isn't found rather than bugging the user. You'll need to insert the proper ID's there, I don't know what they are.
The Ruby API to Google SketchUp has a function, open_file, but I can't find a close_file function. Since I have to batch process many files, I want to close each file before moving on to the next, otherwise the program will crash from memory exhaustion.
What is the best way to close SketchUp files programmatically?
I am using Mac OS X and am willing to use AppleScript functions to signal the window to close.
EDIT
I am considering a few approaches that have proven fruitless so far.
Using the appscript Ruby gem, as described in this question. The problem here is that I cannot get SketchUp to recognize my installed gems.
In a similar vein, I am trying to use osascript (a bash program that executes AppleScripts from the shell) to close the window. That is, I call out to the shell from SketchUp's Ruby console window using one of the following:
%x[osascript -e 'tell application "SketchUp" to close window 1']
%x[osascript -e 'tell application "SketchUp" to close window 1' &]
%x[osascript -e 'tell application "SketchUp" to close every window']
%x[osascript -e 'tell application "SketchUp" to close every window' &]
Whenever I try this second approach, SketchUp just freezes. However, when I execute any of these commands from an IRB or directly from the Bash prompt outside of SketchUp, I get the desired behavior: the model window closes (incidentally, the Ruby console window remains open, which is fine).
Have a master script that launches a slave script to process each model. The slave will run within the Google SketchUp program while the master waits. When the slave is finished, it signals the master, and the master closes the SketchUp file. To do this interprocess communication, I tried using drb. However, when I try to require drb within SketchUp, I get the following message:
Error: LoadError: (eval):5:in 'require': no such file to load -- drb
EDIT 2
Having a separate process continuously running that closes Google Sketchup windows using AppleScript when signaled is clumsy for a number of reasons. First, it's ugly to have to have a separate process devoted to closing Sketchup windows. Second, the only effective way of communicating with the external script is through the creation of files, which is wasteful and the disk access may be slowing things down.
However, the most severe issue is that Sketchup is slow at responding to AppleScript commands. I have a pretty computation intensive script running in Sketchup, and it seems to starve the AppleScript response, which means that the osascript times out before the windows close. Sketchup only gets around to responding to AppleScript when there is a dialogue box prompt in Sketchup that pauses the execution of my computationally intensive script.
EDIT 3
I have modified my close_file function to pause execution of the script by displaying a dialog box. This essentially yields the current thread and allows the thread that responds to AppleScript commands to execute:
def close_file()
f = '/temp/mutex.txt' # for finer control, use different mutex for each window you want closed
File.new(f, 'w').close
result = UI.messagebox "Click OK when window has closed."
end
Then the separate ruby script that closes windows via AppleScript will additionally have to click "OK" in the dialog box. AppleScript to do that is:
tell application "System Events"
tell process "SketchUp"
set frontmost to true
keystroke return
end tell
end tell
This modification is an improvement. It corrects the "most severe issue" mentioned in EDIT 2, but the other issues remain.
There is an important limitation with using an external AppleScript to force SketchUp to do something. SketchUp will not accept any user input while a menu script is running.
I found this out trying to setup an automated rendering solution. I added a menu item which opens a WebDialog to get a list of models to download from a server. It then steps through the list and uses cURL to download each model. Once downloaded it loads the model, renders it out, uploads the images using cURL again, and goes to the next model.
What I wanted was to activate the AppleScript after each model is rendered (using the "mutex" file solution shown above) and have it close the model window. Unfortunately, since the menu script is still running, SketchUp will not respond to anything the AppleScript tells it to do. Only once all of the models have been processed and the menu script exits, will the AppleScript finally run.
This would not be so bad if all of the calls to the AppleScript were queued up, but they aren't. It seems that only the last two get honored (that number may be just an accident dependent on the timing of when my calls to the AppleScript were made relative to when the menu script finished).
Because of this limitation, I was not able to use the mutex wait() function in my menu Ruby code. Since the AppleScript was not able to execute, it never created its "I'm done" mutex file, and therefore the wait() function in Ruby never got the signal that it could continue. The result was a deadlock between AppleScript and SketchUp, such that SketchUp just freezes up (well, actually it is just stuck in a really tight loop in the wait() function).
So, when approaching this problem, think of AppleScript as a cleanup tool you can call when all of your processing is done.
One solution is to have a separate process continuously running that will close Google Sketchup windows using AppleScript when signaled. The approach described here uses files to do the interprocess communication (drb did not seem to work).
First, you have to make sure Sketchup supports AppleScripting. To do this, execute the following at the command prompt (with appropriate substitutions for different Sketchup versions, etc.):
$ defaults write /Applications/Google\ SketchUp\ 8/SketchUp.app/Contents/Info NSAppleScriptEnabled -bool YES
Now, create a separate file that will close Sketchup windows. Here is my closer.rb file:
#!/usr/bin/ruby
## closer.rb ##
def wait(f)
while !File::exists?(f)
end
File.delete(f)
end
def signal(f)
File.new(f, 'w').close
end
while true
wait('~/temp/mutex.txt')
msg = %x[osascript -e 'tell application "SketchUp" to close every window']
signal('~/temp/conf.txt')
end
Run this script from the shell. It waits until the file ~/temp/mutex.txt is created. Once the file is created, it runs osascript (essentially AppleScript) to close all the windows in Sketchup, and then signals that the windows were closed by creating a ~/temp/conf.txt file.
Here is the client code (which can be placed in your Sketchup plugins) that signals the closer script:
def wait(f)
while !File::exists?(f)
end
File.delete(f)
end
def signal(f)
File.new(f, 'w').close
end
def close_file
signal('~/temp/mutex.txt')
wait('~/temp/conf.txt')
end
The close_file signals the closer script and then waits for a confirmation that the file was closed before returning. Now you can close files in Sketchup.
You can do a lot with SketchUp using applescript and/or Automator.
tell application "SketchUp"
activate
tell application "System Events"
delay 1.0 --close window, adjust delay to suit
--key code 13 using command down -- Press ⌘W or you can use
keystroke "w" using command down
end tell
end tell
I have a number of status bar items for open new, paste to console, closing, killing SU etc.
They're tiny files that trigger the SU shortcut keys, and can be used externally, from 'Ruby Console' or as part of a plugin.
I'm not sure what kind of 'batch convert' your trying to achieve, but
I used Automator to convert most of my old v5, V6, v7 files to v8 today...
100's of them,
and your probably aware, on opening you get 'alert' warning that saving will convert the file to the latest version (which is what I wanted).
It's tricky to click this "OK" programatically.
Automator on it's own is quite restricted, but you can add an applescript to the workflow and I've found that if you use it's 'record function' to demonstrate what you need to do.
You can then copy/paste that code into 'Script Editor', get rid of the 'dowithTimeout' bits, copy it back into the workflow with delays either side and let it run.
I had to play around with delays, to accommodate some larger files, but achieved >95% success. [Success being able to select all, right click, Create Icon and Preview.]
Unfortunately I then binned the workflow, but could recreate it, if you want to have a look.
success, in Ruby Console
system("osascript -e 'tell application \"suoff\"' -e 'activate' -e 'end tell'")
and this script inside an Automator.app in applications folder....
on run
-- Make sure SU is foremost, don't click on anything else either
tell application "System Events"
tell process "SketchUp"
set frontmost to true
-- gives a message if you try to select when SU's not running
delay 0.2
tell application "SketchUp" to quit saving no
-- no dialog box etc...
delay 0.1
end tell
end tell
end run
the problem is SU has an anti self destruct ruby, that mines any linked files and aborts all efforts to shut it down... from inside itself.
so you need to bury it...
this combination works on 10.5.8 with SU8.1.
if you have a look at SketchUcation [Developer] Forum, I left a call for mac/applescript testers... I've rewritten the app since then but if you PM me I'll send you an open copy of all the bits I've got working..
john
I had to convert hundreds of .skp files with a batch processing script. I faced similar issue, since every time I opened a new file it remained opened. For me it was enough to close the active_model and the file goes with it.
This was true for SketchUp 2019 Pro Mac OS X version.
model = Sketchup.active_model
model.save(filename, Sketchup::Model::VERSION_2015)
model.close
Hope it will help
So I have this idea for a handy little AppleScript which in my opinion would be very handy in speeding up the process of uploading a local file, to its same location on the server.
In other words, you have to specify the home folder on the server and locally, but once that's finished, it would be nice to just press like "Command" + "Shift" "U" for upload or some other hot key combination not in use by OS X for uploading the currently selected file in the Finder.
I find myself needing to do this a lot, and it will save a lot of time!
Someone please tell me if there is an easier way to do this, but I think this will be a good learning experience on top of it all.
I need some help on how I should get started however..
1) the command line program curl can upload files. 2) if you have a file selected in a Finder window applescript can get the selection. Using those 2 ideas you can automate your task. I don't know the exact curl command but that should be easy to find using google. So you select a file in the Finder and then run the script. The script can be run with a keyboard shortcut as you mentioned or just put it in the Script menu and run it from there.
tell application "Finder"
set selectedFile to item 1 of (get selection)
set selectedFile to selectedFile as text
end tell
do shell script "curl -switchesToUpload " & quoted form of POSIX path of selectedFile
I use Cyberduck which is an ftp client you can set it up so when you double click a file on the server it opens it up in your favorite editor.( textmate is my favorite.) it atuomagiclly downloads and uploads when you save.
this seems like a much better solution to the problem