I have a URL object in AppleScript, and I'm trying to convert it to a text object.
set theURL to "http://apple.com/myfile" as URL
--set t to theURL as text --Fails, can't coerce to text
set a to scheme of theURL --works
set b to host of theURL --works
set c to path of theURL --fails
Can’t get path of {class:URL, scheme:http URL, path:"http://apple.com/myfile", host:{class:Internet address, DNS form:"apple.com", port:80, dotted decimal form:"17.253.144.10"}}.
Clearly, from the error message, the URL object has a 'path' property. My theory is that maybe the word 'path' is reserved? Do I need to escape it somehow?
The example AppleScript code, shown below, was tested in Script Editor under macOS Catalina and macOS Big Sur with Language & Region settings in System Preferences set to English (US) — Primary and worked for me without issue1.
To resolve the issue, in Script Editor, with just using .e.g.,:
set theURL to "http://apple.com/myfile" as URL
--set t to theURL as text --Fails, can't coerce to text
set a to scheme of theURL --works
set b to host of theURL --works
set c to path of theURL --fails
Is to add at least use scripting additions to the top of the script. You might also what to add use AppleScript version "2.4" -- Yosemite (10.10) or later.
So, in Script Editor, e.g.,:
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
set theURL to "http://apple.com/myfile" as URL
set c to path of theURL
Notes:
The is no conflict with path being a keyword (or reserved) as it it just not a keyword! See: AppleScript Keywords
Also see the screenshot below of the Library in Script Editor for Standard Additions.
This issue is solely due to the fact that use scripting additions must be used in the context of your example AppleScript code.
Assuming you are running Yosemite (10.10) or later, generally speaking, it typically is safe to add the aforementioned lines to your scripts. Personally I only add them as needed.
1 Assumes necessary and appropriate settings in System Preferences > Security & Privacy > Privacy have been set/addressed as needed.
From the Library in Script Editor (⇧⌘L) for Standard Additions:
As you can see path is a text read-only property of URL and is easily retrievable when using use scripting additions as show above.
Update:
To refute the false allegations made by Robert Kniazidis of me in comments under my answer, ...
... which reference his answer at the time of my comments, here are three screen shots taken after his latest rewrite of his previously deleted answer and since the time of my comments, that confirm what I said.
In the first screen shot I again copy and paste the first block of code into Script Editor, and as one can see it's in purple, meaning it hasn't yet been compiled.
The second screen shot shows having hit the Run button, which compiles the code and executes it. As one can clearly and plainly see, it did exactly what I previously stated, it automatically changed set c to «property FTPc» of theURL to set c to path of theURL and resulted in the error I mentioned, which is also mentioned in the OP and is the issue of the question asked!
In the third screenshot I added use scripting additions and ran the script again, resulting in the expected output and no errors as in the OP or my statements of fact that I'm being accused of lying about.
I was able to replicate these results in both macOS Catalina and macOS Big Sur on two different machines using Script Editor, the Apple default application for AppleScript, and Script Debugger, a third-party application, that is designed to be superior to Script Editor.
Yes, it conflicts with some other path property («property ppth»). Use instead following. After compiling the code it will reference to proper path property:
set theURL to "http://apple.com/myfile" as URL
set c to «property FTPc» of theURL
Or, in the following form (this form allows you to deliver already compiled code to other users, as is):
set URLpath to run script "set theURL to \"http://apple.com/myfile\" as URL
set d to «property FTPc» of theURL"
Related
I have some AppleScript which I run via osascript on the command line.
The script itself looks like:
on run argv
set appname to item 1 of argv
set tmp to item 2 of argv
set jsfl_path to POSIX file tmp
if application appname is running then
tell application appname
with timeout of 600 seconds
open jsfl_path
end timeout
end tell
end if
end run
I updated Adobe CC Animate to the latest version. I was previously running the 2018 version. It turns out they renamed the file pattern. It used to be Adobe Animate CC 2018. Now it is Adobe Animate 2019.
Here is where the problem starts. In my script I was sloppy and change the name to Adobe Animate CC 2019.
When I ran the AppleScript, it produced a dialog to Choose Application. In my haste, I accidentally mapped it to the wrong program.
I'd like to remove this mapping. What I cannot find is where this mapping is stored. Does anyone know where this type of mapping gets saved?
It isn’t really stored anywhere, the Script Editor uses your declarations to determine where to load the scripting terminology from. Recompiling the script after making an edit should reset things, otherwise you can restart the Script Editor. Note that you need to use a specific bundle identifier or application name - using a variable to specify the application can be problematic, as the terminology is loaded at compile time.
I am trying to incorporate my applescript into xcode. the script works normally with applescript but not ran in xcode. I am trying to open the file for reading. here is the code
set Location to "US"
set DriverFile to "/Volumes/MacPrintDrivers/" & Location & "DriverInstall.txt"
set DriverInstallFile to POSIX file DriverFile
open for access DriverInstallFile
i have confirmed the file exists and i can display the contents. i can't seem to read this way in Xcode. the error i get is
«script» doesn’t understand the «event rdwropen» message. (error -1708)
ASOC (AppleScript Objective-C) has some problems with scripting addition commands (such as open for access). Sometimes you can work around this by saying tell current application to, e.g. tell current application to open for access. But for further details I suggest you get Shane Stanley's book: http://www.macosxautomation.com/applescript/apps/ He has explored this in great depth.
How is it possible to set the black dot in the close button of a window using applescript?
From http://docs.realsoftware.com/index.php/Window.ContentsChanged_property, I would guess something like:
tell app "CurrentApp" to set ContentsChanged to true of window 1
But it doens't work: execution error: CurrentApp got an error: Can’t make ContentsChanged of window 1 into type specifier. (-1700)
Also, how can I get what the current application is with applescript?
This question is related to Signifying unsaved changes by prepending * in window title - how to add a black dot in the window close button on Mac OS X?
To answer the second part of your question s first: you can get the current application with "the frontmost application", for example
tell application "Finder"
set frontApp to the path to the frontmost application
end tell
The short answer to the first part of your question is: it is currently impossible to do what you want. Long answer follows below.
From your comments, I understand you are using Python with TCL/TK to build the GUI.
Not every application is able to set the "contentsChanged" indicator (apparently, this is what it is called in RealBasic but not in Apple's API). Check the AppleScript dictionary of the application. Relying on what I read elsewhere, TextEdit used to be able to set the "modified" property of its documents but when I try this in Mac OS X 10.6.8 it no longer works.
If you're using a native Cocoa application, you might be able to set this indicator by adding and removing a space to the document with some GUI scripting, e.g. type a space and use the Undo menu item to remove it. Unfortunately, when I try this in TextEdit, the Undo command also removed the indicator.
I checked Apple's API documentation and there appears to be a method SetDocumentEdited in the NSWindow class. Unfortunately, Apple doesn't describe properly what it does, but it appears to set the dark spot in the red close button if the DocumentEdited property is set to true. You can read about it here. If you're using TCL/TK, it would have to be able to call the SetDocumentEdited method somehow.
You can't tell the operating system to change the DocumentEdited property of a window (which would be the equivalent of the "modified" property you found in an AppleScript dictionary). The (Python-TCL/TK) application you're talking to needs to have this implemented. If TCL/TK doesn't have a command for this, then it is probably impossible, no matter if you use AppleScript or Python or something else. I'd suggest you ask on a TCL/TK forum if someone can write and compile a kind of plug-in to implement this feature.
I am having significant issues creating a very simple AppleScript to export attachments from an Evernote note. I have used the following code several times and it seems to work, but in actuality it fails silently, even though the event log shows a correct response.
I have heard that Evernote's recent versions have significant AppleScript support issues. If someone out there is an Evernote and AppleScript "expert", I would also greatly appreciate a review of my script to make certain I'm not forgetting anything.
I am using Mac OS X 10.8.2 and the Mac App Store version of Evernote 5.0.5 (400805).
Code:
set ExportPath to "LegatusHD1:Users:me:Downloads:Test"
set theAttachments to {}
set selectedItems to {}
tell application "Evernote"
set selectedItems to selection
repeat with selectedItem in selectedItems
set theAttachments to (attachments of selectedItem)
repeat with theAttachment in theAttachments
set theFilename to (ExportPath & ":" & theAttachment's filename)
write theAttachment to theFilename
set theFilename to ""
end repeat
end repeat
end tell
Apple has introduced sandboxing for apps from the AppStore recently. So depending on your OSX version, this might be the reason why it fails silently - since the Evernote app is not able to access the file system outside its own folder structure. You can try setting the export path to be something within the Evernote folder.
This question is old but I just tripped over it looking for an answer which I can now provide:
FYI I am running: OSX 10.9.1 (Mavericks) and Evernote 5.4.4 installed via App Store.
I can confirm that Mustafa was right, using the App Store version of the app it is only possible to write to files within the sandbox (/Users/{username}/Library/Containers/com.evernote.Evernote/)
Short answer
Either install the app from the Evernote website or if you want to use the one in the App Store:
Using the above script change the export path to something inside the sandbox e.g.:
set ExportPath to "Users:{username}:Library:Containers:com.evernote.Evernote:Data:attachment_export"
Remember to make the attachment_export folder first, and replace the {username} with your username
A note on debugging
Unfortunately applescript editor doesn't show any errors when you try to write outside the sandbox. You can however view the error in the Console application (found in Applications -> Utilities). In Console enter 'sandbox' in the search box (top right hand corner) and at the bottom of the window you will see something like this:
1/29/14 10:22:29.426 sandboxd[310]: ([4433]) Evernote(4433) deny file-write-create /Users/{username}/Desktop/Evernote Snapshot 20140128 134741.jpg
I have a semi-long AppleScript that I run each morning to launch all of my apps etc. One of the things that it does is launch a few apps and then immediately minimize them. When I paste the .applescript source into Script Editor and run it, everything works fine:
-- snip:
tell application "Mail"
launch
minimize(window 1) of me
check for new mail
end tell
-- 'minimize' defined as:
on minimize(w)
set the miniaturized of w to true
end minimize
But when I compile the AppleScript source as follows:
osacompile -o ~/Library/Scripts/myscript.scpt myscript.applescript
... the compiler munges minimize to be:
on minimize(w)
set |miniaturized| of w to true
end minimize
And I get this error:
error "Mail got an error: Can’t make |miniaturized| of window id 30936 into type reference." number -1700 from |miniaturized| of window id 30936 to reference
Anyone have any clue what I'm doing wrong here? For purposes of version control, I need to run the scripts through osacompile.
UPDATE: To clarify, what seems to be happening is that Script Editor is compiling the method differently than osacompile on the command line. Is it known whether they compile different (e.g., using scope inferences or some such thing)?
There is nothing wrong with your code - I suspect this is a bug in osacompile and I suggest you file a bug report with Apple - as I've done.
You can verify that your code works correctly by using AppleScript Editor to save it as a *.scpt file directly and then running it with osascript.
[Updated] By contrast, passing the *.applescript source-code file directly to osascript does exhibit the problem.
There is no good reason I can think of for AppleScript Editor-based compilation to work differently from osacompile (and on-demand compilation in osascript), and the former's behavior is the expected and desired one in this case.
There are 2 workarounds:
Enclose the reference to miniaturized in a using terms from application "System Events" block:
This is a generic workaround that should work with windows from any AppleScriptable application.
on minimize(w)
using terms from application "System Events" # WORKAROUND
set miniaturized of w to true
end using terms from
end minimize
Inline the miniaturization command instead of calling a subroutine:
set miniaturized of window 1 to true
on minimize(w)
set the miniaturized of w to true
end minimize
This is not correct. You have "miniaturized" outside any application tell block of code, which means that it's an applescript command. It isn't an applescript command though. It's a command of Mail and other applications. It's amazing that it works properly in AppleScript Editor. It really shouldn't. When you have a command that doesn't make sense applescript is good enough to try to make sense of it and sometimes it can overcome your coding mistake. Obviously osacompile can't overcome your coding mistake.
So the way to fix the osacompile issue is to eliminate the coding mistake. You need to have the miniaturized command inside of an application tell block of code.
To see what I mean open the "standard additions" applescript dictionary and try to find the miniaturized command. you won't find it. Now open Mail's applescript dictionary and you will find it. Thus the command belongs to Mail, not applescript.