Main

September 30, 2006

So now, one of my long standing beefs with Acrobat on the Mac has been the Office integration macros, and how PDFMaker on the Mac is really just a big dumb "Print To File" button that uses Distiller instead of the Mac PDF generation.

Adobe's reasons have always been, "We need access to things that Word on the Mac can't give us". Okay, but then I got to wondering. Why NO improvement at all? I mean, okay, so we can't get full feature parity. But nothing since Acrobat 5? That didn't sound right. So I decided to see if there weren't perhaps some things that could be done to improve the situation. I mean, even InDesign can at least render URLs in Word files, hell, so can Acrobat if you dump the Word file to HTML then import that into Acrobat.

So I got to looking and I discovered, thanks to Script Debugger's really excellent dictionary browser that lets you see what the dictionary is seeing live. (Really, if you want to use AppleScript more than once, and you don't have Script Debugger, you're being quite foolish.) In fact, there are at least two items that you can get to via AppleScript: URLs and Tables of Content, or TOC. I even took some screen shots to illustrate. First, the TOC for the document, an article I did for MacTech back in 1999:

That's a "live" TOC. If you click the page number you go to that page. Quite useful. Now, here's the screenshots for the TOC property of that same Word file in Script Debugger:

Note here, we get the four heading styles used in the TOC. Script Debugger even gives us the basic AppleScript properties statements too: "heading style 1 of table of contents 1 of active document". That's pretty handy. But it doesn't give us anything to really look for, like the text we'd need, and the page it links to. Until we get here:

If we look at the contents, we see the name of the link, and the page it links to. Wow, that's pretty handy. We now have the information required to tell us the text in a TOC entry and the page it links to. What if we didn't want to parse it all though? Not a problem, Word's dictionary gives us another way to get this information:

If we look in the sentence property of the TOC we see that the contents of sentence 1 of text object of table of contents 1 of active document gives us "NETWORK INNOVATIONS\t\3\r" which shows that there's a tab between the TOC entry and the destination page, followed by a return. Wow, not only the content and page link, but some formatting too.

What about URLs? Even simpler:

Content and text. Right there. Oh, and Word has the find feature as a part of its dictionary, and you can search by formatting too. So that's not a huge problem either.

Now, I'm not going to tell you that adding these features into the macros would be easy. I've been scripting for far too long to say that. It's not easy at all, but it's not impossible, which is what Adobe's been saying it is. It may be impossible to add in all the functionality of the Windows version, but it is not impossible to improve the existing macros. Word's VBA allows for the execution of AppleScripts, and Acrobat's rather small dictionary allows for the execution of Javascripts. So the way to go from button to AppleScript to Acrobat to JavaScript to PDF is there. (In Acrobat's miscellaneous suite it's the "do script" command and it takes either the actual Javascript text, or an alias to a Javascript file as parameters.)

That's the part that pisses me off. The Acrobat team says "we can't get to that information", yet there it is. I find it impossible to believe that no one on that team knows about AppleScript or is incapable of doing what I did to find out this information. The only reason that would let them say "Impossible" is if they only accept 100% feature compatibility with the Windows version as the minimum acceptable improvement, and it has to be done use the same code as the Windows version.

But that can't be it right? Because that would be...kinda...I dunno...silly?

Technorati Tags: Acrobat, Adobe, Adobe Applications, AppleScript, Microsoft, Microsoft Mac BU, Microsoft Word

Comments

So now, one of my long standing beefs with Acrobat on the Mac has been the Office integration macros, and how PDFMaker on the Mac is really just a big dumb \"Print To File\" button that uses Distiller instead of the Mac PDF generation.\n\nAdobe's reasons have always been, \"We need access to things that Word on the Mac can't give us\". Okay, but then I got to wondering. Why NO improvement at all? I mean, okay, so we can't get full feature parity. But nothing since Acrobat 5? That didn't sound right. So I decided to see if there weren't perhaps some things that could be done to improve the situation. I mean, even InDesign can at least render URLs in Word files, hell, so can Acrobat if you dump the Word file to HTML then import that into Acrobat.\n\nSo I got to looking and I discovered, thanks to Script Debugger's really excellent dictionary browser that lets you see what the dictionary is seeing live. (Really, if you want to use AppleScript more than once, and you don't have Script Debugger, you're being quite foolish.) In fact, there are at least two items that you can get to via AppleScript: URLs and Tables of Content, or TOC. I even took some screen shots to illustrate. First, the TOC for the document, an article I did for MacTech back in 1999:\n\n\n\n\n\nThat's a \"live\" TOC. If you click the page number you go to that page. Quite useful. Now, here's the screenshots for the TOC property of that same Word file in Script Debugger:\n\n\n\n\n\nNote here, we get the four heading styles used in the TOC. Script Debugger even gives us the basic AppleScript properties statements too: \"heading style 1 of table of contents 1 of active document\". That's pretty handy. But it doesn't give us anything to really look for, like the text we'd need, and the page it links to. Until we get here:\n\n\n\n\n\nIf we look at the contents, we see the name of the link, and the page it links to. Wow, that's pretty handy. We now have the information required to tell us the text in a TOC entry and the page it links to. What if we didn't want to parse it all though? Not a problem, Word's dictionary gives us another way to get this information:\n\n\n\n\n\nIf we look in the sentence property of the TOC we see that the contents of sentence 1 of text object of table of contents 1 of active document gives us \"NETWORK INNOVATIONS\\t\\3\\r\" which shows that there's a tab between the TOC entry and the destination page, followed by a return. Wow, not only the content and page link, but some formatting too. \n\nWhat about URLs? Even simpler:\n\n\n\n\n\nContent and text. Right there. Oh, and Word has the find feature as a part of its dictionary, and you can search by formatting too. So that's not a huge problem either.\n\nNow, I'm not going to tell you that adding these features into the macros would be easy. I've been scripting for far too long to say that. It's not easy at all, but it's not impossible, which is what Adobe's been saying it is. It may be impossible to add in all the functionality of the Windows version, but it is not impossible to improve the existing macros. Word's VBA allows for the execution of AppleScripts, and Acrobat's rather small dictionary allows for the execution of Javascripts. So the way to go from button to AppleScript to Acrobat to JavaScript to PDF is there. (In Acrobat's miscellaneous suite it's the \"do script\" command and it takes either the actual Javascript text, or an alias to a Javascript file as parameters.)\n\nThat's the part that pisses me off. The Acrobat team says \"we can't get to that information\", yet there it is. I find it impossible to believe that no one on that team knows about AppleScript or is incapable of doing what I did to find out this information. The only reason that would let them say \"Impossible\" is if they only accept 100% feature compatibility with the Windows version as the minimum acceptable improvement, and it has to be done use the same code as the Windows version. \n\nBut that can't be it right? Because that would be...kinda...I dunno...silly?\n\n

Technorati Tags: Acrobat, Adobe, Adobe Applications, AppleScript, Microsoft, Microsoft Mac BU, Microsoft Word

September 24, 2006

Okay, so when I see where Adobe has yet to make it easy to build PDFs from Entourage messages, (or Mail messages for that matter), it bugs me. Yes, I know, you can't make the happy little buttons in Entourage, and it's not easy to do it in Mail, (if you even can at all), but that's not the same as it being impossible. I mean, come on, this is so not just an Outlook thing.

First, Entourage can show you the source of a message, which means you can parse it for HTML and the like. Hell, E'rage will tell you outright if a message has HTML. It's in the Entourage Mail and News Suite. Whether it does or doesn't, it's child's play to get the source of the currently selected message in Entourage. Literally. Two lines for the tell block, one to get the currently selected message, one to get the source of the currently selected message.

In fact, the biggest stumbling block is (shock), Acrobat, whose AppleScript Dictionary blows, and you should really just use Javascript for Acrobat. Partially because that's just the best language for scripting Acrobat. Well, almost entirely because of that. But luckily, Acrobat's AppleScript dictionary does allow you to execute a Javascript. So you can eventually get there from here. (Does anyone out there with more experience on the VBA side of things know if the VBA implementation in Acrobat for Windows is as poor as the AppleScript implementation is in Acrobat for OS X? Either way, a quick comment with your opinion of the VBA implementation would be appreciated.) Yes, it's also possible I fubared the capture web page statement. That would then be an ID10T error on my part, however, the Acrobat dictionary still blows, and you should use Javascript, because in Acrobat, Javascript does not blow.

Anyway, I was playing with this a bit, and here's the source. The reason I was playing with this was because I was earlier playing with generating PDFs from Word files converted to HTML. Yes, Word's HTML sucks, but that's not the point. The point behind that was to see if I could generate, from Word 2004 on Mac OS X, a better PDF than the Adobe Macros can. You know, the ones that haven't improved in a dog's age, because Adobe says it can't happen until Office gives them more access? Yeah, guess what. Just by saving as HTML, then using Acrobat's ability to create a PDF, I was able to create a PDF from Word in Acrobat with live Internet URLs. Wow. Looks like some improvement is possible. Because it's not like Adobe wouldn't even try to improve them even slightly if it were possible? Say with a button that exported it out to HTML in a temp file. That button would then kick off an AppleScript which ran an Acrobat Javascript which then read that HTML, (as crappy as Word's HTML is, it's consistently crappy, which means you can work around it), and created a PDF with more structured features than you currently get out of the "LOOK! I MADE A PDF, YAAAAY!" that are the Adobe macros.

There's just no way that would work at all as a way of saying, "Look, it's not as good as what you get on the Windows side, but it's something of an improvement." Or maybe looking at what you can pull out of a Word file via AppleScript and creating a javascript temp file from it which Acrobat could then run and build a PDF. No, that must be impossible too. There's no way to get all the hyperlink objects of a document. Or get the TOC entries and the pages they link to from the tables of contents of a document so that you could then make those links live in the PDF. Or figure tables. I mean, again, I'm not expecting 100% compatibility. But, some improvement in the last six years or so would be nice.

'Cause there's just no way that the Acrobat team would refuse to do something unless they could do it the exact same way on both platforms, right? That'd be really silly and something you expect from an inexperienced intern, not a multinational made up of mature grownups focused on delivering the best possible solutions for Acrobat customers using Office 2004.

So anyway, about that E'rage script. Now, I did this based on one message, a Classmates.com message. So there's a lot of stuff that would be inappropriate in a more general script. But, you can indeed dump that source to a file that Acrobat can build a PDF of. It's not perfect, but it's not impossible either. Stick it in the E'rage script menu, and you'd have a spiffy damned solution. I'm a tad bit too busy to finish it, but please, take it and have fun with it. Make it rock, then, if you could, give it away. Even my good friends at Adobe, please, feel free to use this. I know you guys meant to do this, but have just been too busy to get it out there.

tell application "Microsoft Entourage"
     set theMessageList to the selection
     repeat with x in theMessageList
          set theMessageSource to source of x
          set theHTMLStart to offset of "<html>" in theMessageSource
          set theHTMLStop to offset of "</html>" in theMessageSource
          if theHTMLStop = 0 and theHTMLStart ≠ 0 then
               set theBadHTMLTagFlag to true
          else
               set theBadHTMLTagFlag to false
          end if
     end repeat
end tell

set theSystemInfo to system info
set theHomeDir to home directory of theSystemInfo as text
set theDocumentsFolder to theHomeDir & "Documents:"

try
     set theTempFolder to (theDocumentsFolder & "erage2pdf:" as alias)
     on error theErrorMessage number theErrorNumber --test the error
     if theErrorNumber = -43 then ---43 is the error number for folder doesn't exist, so that's the only time we want to create it
          --you can add code for other errors if you like
          tell application "Finder"
          make new folder at (theDocumentsFolder as alias) with properties {name:"erage2pdf"} --make the folder
          end tell
     end if
end try

set theTempFolder to (theDocumentsFolder & "erage2pdf:" as text)
set theTempFilePath to (theTempFolder & "messageTempFile" & (time of (current date) as text) & ".html")
set theTempMessageFile to open for access theTempFilePath with write permission
write theMessageSource to theTempMessageFile
set theTempContents to read theTempMessageFile from theHTMLStart
set eof theTempMessageFile to 0
write theTempContents to theTempMessageFile

if theBadHTMLTagFlag then
     set theTempMessageFileEOF to get eof theTempMessageFile
     write "</html>" to theTempMessageFile
end if

close access theTempMessageFile

tell application "Finder"
set theTempFileURL to URL of (theTempFilePath as alias)
end tell

set theTempFileURL to theTempFileURL

tell application "Adobe Acrobat 7.0 Professional"
     set thePDFConvert to capture web page theTempFileURL into New Document
end tell

Technorati Tags: Acrobat, Adobe, Adobe Applications, Apple, AppleScript, Microsoft, Microsoft Entourage, Microsoft Mac BU

Comments

August 29, 2006

The only real change is that I moved back into Xcode/Studio to make it a Universal binary. Compressed size is about 92 K. It's just a nicer way to enter manual iChat statuses without the evergrowing list that iChat gives you.

get it here

Technorati Tags: AppleScript, Mac OS X

Comments

July 28, 2006

First, the major caveat:

THIS IS A NOT READY FOR PRIME-TIME APPLICATION

There's a bunch of things in it that would need to be done to make it something you want to rely upon. It's a demo/proof of concept that you could, if you like, use as a start for doing spiffy things with Apple Remote Desktop and AppleScript.

I wrote this because I wanted to see about using AppleScript with Apple Remote Desktop to create something a little more automatic than the Apple Remote Desktop menu widget allows for. The only real pain here was, unsurprisingly, Mail, which, in Mac OS X 10.4, is having some...issues in its dictionary. This is designed to work with both Mail and Entourage. The Mail setup is a bit more complex due to the workarounds I had to do when dealing with Mail's issues. I picked Mail because it's something that I can assume will be on every install of Mac OS X, and Entourage, because it's my client of choice, and it has one of the best AppleScript dictionaries of any email application. The whole thing is available as a proof of concept demo from here.

The Get help application, when run, pops a dialog allowing a user to enter a short problem description. This, and certain system information items are then packaged in an email to the person running the Apple Remote Desktop administrator console. It pops an alert notifying them that someone has a problem, with the problem description, User name (long and short), UID, home directory path, user computer name, user OS version, and user IP address. It also instructs Apple Remote Desktop to open an observe window on that computer. Obviously, you need to have the computers you run this on in Apple Remote Desktop for this to work. From my POV, this is of more use in a lab situation, but you could adapt it to almost any Apple Remote Desktop setup.

On the administrator machine, there are two paths for this to take:

With Entourage, the message from the user is grabbed by a rule, which kicks off an AppleScript. The AppleScript reads the contents of the email, parses them out, presnts the administrator with the alert message, and opens the observe window on the user's computer in Apple Remote Desktop.

With Mail, the end result is the same, but the process is more complicated. I simply couldn't get the display alert step to not terminally stall in Mail, so I had to come up with a workaround. In Mail, the message comes in, the rule grabs it, and kicks off the script. However, instead of directly popping the alert, the message contents are written to a text file in a directory in the administrator's Documents folder that has a folder action attached to it. Once that file is written, the script then has Apple Remote Desktop pop the observe window. The folder action graps the contents of the text file, and pops the alert telling you about the problem.

CAVEATS AND DISCLAIMER:
I tested this on 10.4.7 8j135. If you are running an earlier (or later) version of the Mac OS, and something doesn't work, I'll try to help you if I have the time. I didnt regression test this AT ALL, since it's just a proof of concept. I think there are a few things that just won't work in anything pre-Tiger, but if you want to make it work in Mac OS X 10.3, feel free. As always, there's no warranty or implied warranty or even possible warranty. If it works, great! If it doesn't, that's too bad. If it somehow magically, (and it would HAVE to be magic) causes your mac to melt, your toilet paper to turn to sandpaper, and your house to be posessed by an evil clown, not my problem. (Although I may want to buy your house, that would be so cool.) This is, as always, free. The source is included. Don't just blindly run this without reading this document AND THE SOURCE CODE. I comment heavily, so reading the source is of some benefit. Besides, it won't work if you dont' set up a few things in the "Get Help" application anyway.

LICENSE:
Xmail is licensed by its creator, Jean-Baptiste LE STANG. Please go to his site for any Xmail info. I'd like to thank him for it, as it made this little demo MUCH nicer to write, and it's a way spiffy bit of code. If you're going to use this demo heavily, please do send him a donation.

My work in this is as always, creditware. It's free, do what you will with it. But, if you add some neat features, please, just leave my name in the comments somewhere, and add your own with your additions. I think it's really cool when I get an application, and I learn who did what on it. It's a history of the application, and I'm a history maven.

INSTALLATION

"Get Help" application component

Pre-installation:

Open up the "Get Help" application and set the blank properties to the values you need. For my testing, I just hardcoded stuff. That's a bit of a kludge I think, but again, this isn't a full-on application. (Don't complain, you aren't paying for it, now are you? No, no you are not.) If you want, you can probably pull the current user's email address and login info from the system or the Keychain if you like. There are also good reasons to staticly enter this information, there are good reasons not to, it's up to you. Either way, it's a fairly self-containted little applicaiton. It uses the Xmail 3.5 OSAX, which lives in the application's resources folder. Xmail is free, it's GPL'd. However, if you are going to actually use it, then please, do make a donation to it's author. The information is in the Xmail Readme, included in the zip for this application.

Installation: I recommend placing Get Help in the dock or desktop for whatever users you want to have access to this. MCX can be a help here.

Get Help's entire purpose is to send an email with specific information to a specific email address.

entouragegethelp.scpt:

This is the script that you use with E'rage. Create a rule that is kicked off when the "Get Help" application's email comes in, (I used the subject line, but it's up to you), and attach this rule to it. That's it. Message comes in, rule runs script, script pops dialog and runs Apple Remote Desktop. Voila!

mailgethelp.scpt:

This is one of the scripts you use with Mail. Create a rule that is kicked off when the "Get Help" application's email comes in, (I used the subject line, but it's up to you), and attach this rule to it. That's the first part. This will get you the observe window in Apple Remote Desktop, and a text file written to ~/Documents/getmailhelp folder/. (Note that while this script will create the folder if it's not there, it will NOT handle the folder action parts automatically.) I keep this in the user's home directory, because well, that's what home directories are for, and in documents because Library is too much of a catchall, and this is creating documents. The text file is so that you can get the alert in the second part of using Mail with this. The second part is handeled by a folder action, mailgethelpfolderaction.scpt.

mailgethelpfolderaction.scpt:

This is the script that handles popping the dialog, since Mail has issues with it. (Note, if anyone comes up with a fix for this, PLEASE let me know? jwelch@bynkii.com). This folderaction can be attached to any file, but the path in the script(s) assumes ~/Documents/getmailhelp folder/. The file hits the folder, the folder action reads the contents of the file, dumps them into an alert, and bang, done.

I have filed some bugs on Mail's AppleScript implementation based on Mail's quirks. Hopefully, they'll get fixed soon.

Again, this is just a proof of concept, to show some of the ways you can use AppleScript with Apple Remote Desktop, Mac OS X, and other applications to build support systems on your own. Sometimes, you just need to do it your way.

HUGE MONSTER THANK YOU!
To Mark Aldritt and Late Night Software for Script Debugger 4. I cannot imagine writing AppleScript without Script Debugger, nor do I wish to try. It has far too many features, like the reminders about open file handlers, the glory of its dictionary browsers, the ease of debugging things like folder actions and scripts run from email rules that just spoil me silly, and without it, I'd still be working on this. Actually, no, I wouldn't, because without Script Debugger, I'd not even bother trying.

Technorati Tags: Apple Remote Desktop, AppleScript, Mac OS X

Comments

July 6, 2006

This is one I wrote up today after getting tired of the way things normally decompress/dearchive in the Finder for me. It takes advantage of something I found via running "strings" on BOMArchiveHelper's executable. All it does is take a selected file or files in the Finder and dearchives them and any archives inside of them until there's no archives left to work on.

property fileAliasList : {} --property for a list of aliases to files
property theBOMArchiveHelperCommand : "/System/Library/CoreServices/BOMArchiveHelper.app/Contents/MacOS/BOMArchiveHelper dearchive-recursively " --the command to tell BOMArchiveHelper to recursively expand/dearchive things
property goodListLength : false --flag we use for error checking

tell application "Finder" --since we're selecting files in the Finder, we have to use that
     set theFileList to the selection --get the selected file(s)
     if length of theFileList > 0 then --if there's at least one selection, cool, otherwise nothing happens
          set goodListLength to true --set the flag to true
          repeat with x in theFileList --iterate through the list
               set the end of fileAliasList to (x as alias) --get the location of each file in the list as an alias
          end repeat --end of the repeat loop
     else
          set goodListLength to false --zero length list, no love
     end if
end tell

if goodListLength then --if the error flag is true
     repeat with x in fileAliasList --iterate the list of aliases
          set theFilePath to POSIX path of x --get the posix path of an item, since BOMArchiveHelper won't play with aliases
          do shell script theBOMArchiveHelperCommand & theFilePath --run our pre-built BOMArchiveHelper command with the posix path to the file
     end repeat --end the repeat loop
end if

That's it. Pretty simple, but it makes my life a wee bit easier.

Technorati Tags: AppleScript, Mac OS X

Comments

July 5, 2006

Since I've posted, and recently updated my Apple Remote Desktop Script Collections, I thought it might be fun to walk through some of them. None are all that big, but they do make some common tasks easier. Obviously, these require Apple Remote Desktop 3 or later, since prior to 3, Apple Remote Desktop wasn't scriptable. I'm not going to do them all in one article either.

One of the things that annoys me is how, even though Apple Remote Desktop can install Apple Install Packages to hundreds of remote machines, you have to select the machines manually, and drag and drop the installer, set the options, etc.

That's monkey work, and smart administrators automate that. Instead of using Automator for this, you just use vanilla AppleScript and folder actions. (If you want to be really geeky, you could use launchd to handle the folder action part, but there's not a lot of advantage to this since you have to be running in a console session to use Apple Remote Desktop anyway.)

The simplest one is an action I use to update my Virex installs. First, I created a computer list called Virex Updates and populated it with the systems that are running Virex. Then I created the script and attached it to a folder on my desktop. Now, I just drop the Virex update package in the folder and Apple Remote Desktop handles it from there. I don't have to do anything else. Much simpler. If I really wanted to be slick, I could tie this into a launchd item that only ran when I was logged in that looked for new updates automatically, and did this all for me. This particular script doesn't use a task server, but you could easily use one with it. The code with line numbers follows:

1. on adding folder items to theFolder after receiving theAddedItems --this starts the folder action
2.      repeat with x in theAddedItems --theAddedItems is the list of items you dropped on the folder
3.           set theFileInfo to info for x --get info for the downloading file(s)
4.           set theBaseSize to size of theFileInfo --get initial size
5.           delay 3 --wait 3 seconds
6.           set theFileInfo to info for x --get info again
7.           set theCompareSize to size of theFileInfo --get a newer size
8.           repeat while theCompareSize ≠ theBaseSize --if they don't equal, loop until they do
9.                set theBaseSize to theCompareSize --new base size
10.                delay 3 --wait three seconds
11.                set theFileInfo to info for x --get info
12.                set theCompareSize to size of theFileInfo --get a newer size
13.           end repeat --once the sizes match, the download is done
14.      end repeat
15.      tell application "Remote Desktop" --The actual Apple Remote Desktop part
16.         set thePackageInstall to make new install package task with properties {delegating to task server:false, encrypting:true, packages:theAddedItems, stopping on error:false} --build the install task
17.           set theTaskResult to execute thePackageInstall on computer list "Virex Updates" --execute the install task
18.           display dialog (status of theTaskResult as text) giving up after 60 --OPTIONAL. A little indicator of what happened.
19.      end tell
20. end adding folder items to --end of script

Now, going through line by line:

Lines one and twenty are the folder action handler. In this case, "adding folder items to", since that's the action that kicks everything off.

Lines 2 through 14 are there to deal with the fact that there's not a great way of monitoring the status of a file in all situations, and the fact that the "adding items to" action will happily kick off, even though the item's not finished being moved or copied. The Finder Busy Flag doesn't always kick in for all transfer types, so I just use a three second delay and compare loop. If the size hasn't changed in three seconds, it must be done. If you need a longer delay, adjust as necessary.

One point of reference; no matter how many items you drop on a folder with this kind of action attached to it, they're always referenced as a list. This can be inconvenient sometimes, but as we'll see, for scripting Apple Remote Desktop installer actions, it's the perfect way to do this.

Now, lines 15 through 19 are the Apple Remote Desktop tell block.

Line 16 is where we build the install task. With Apple Remote Desktop, pretty much everything you do via scripting is a task, so the standard algorithm is build the task, execute the task. The task we're building is an install package task, so we set thePackageInstall to make new install package task. The specific properties are as follows:

• delegating to task server:false. [OPTIONAL] If you're using a task server, (and I highly recommend it), set this to true.
• encrypting:true. [OPTIONAL]This is just too easy to use, and adds a layer of protection to your installs. There's no reason to not enable this.
• packages:theAddedItems. [MANDATORY]This property is a list of packages you want to install. Remember how I said that the adding items folder action uses a list? Well, so does this property, so we just use the same list that was created when you dropped the packages on the folder.
• stopping on error:false. [OPTIONAL] This is so that if someone shuts off one of the target computers that you're installing to, it doesn't halt the install to every other computer in the list.

Line 18 is totally optional, and one I don't really use, since it makes this be a background thing only, and that is a dialog with the final result of the task. But it's useful for testing.

That's the whole script. There's a lot more you can do with it, error checking, etc., but it's a good little shell. Note that if you have multiple packages in theAddedItems, they all go out as one task installing multiple packages, not multiple tasks each installing a separate package. You can change that by iterating through theAddedItems, and building each task separately if you prefer.

I'm going to be doing more of these little "Fun with Apple Remote Desktop 3 Scripting" articles in the coming days, so if you have any specific requests, put them in the comments here, and I'll see if I can help you out.

Technorati Tags: Apple Remote Desktop, AppleScript, Mac OS X

Comments

May 8, 2006

So here's what I do on the weekends. You have to be running at least Mac OS X 10.3 and iChat. No, there's no windows version. Windows sucks.

iCornhoolio

Technorati Tags: AppleScript, Beavis and Butt-Head, Stuff that doesn't suck

Comments

April 14, 2006

I put up a couple folder actions and some script menu scripts for Apple Remote Desktop 3, with copious comments and readmes and descriptions, all of which should be read, as they answer many questions. They're mostly to show some examples of what you can do with AppleScript and Apple Remote Desktop 3. (Yes, it MUST be 3, no earlier versions are scriptable.)

Make with the clicky-clicky

Oh, and if you are going to play with Folder Actions, you'll want to debug them, and in that case, the ONLY way to fly is Script Debugger. It's the bomb-diggity.

**Update**

Okay, so I think this is really cool. Apple linked to my scripts! (it's in the AppleScript section: "Download an Apple Remote Desktop 3 script collection.")

Wheeee!

Technorati Tags: Apple, Apple Remote Desktop, AppleScript, Folder Actions, Mac OS X, Technology

Comments

April 11, 2006

Apple just released version 3 of Apple Remote Desktop, and it's a release that has earned a new version number. While there are a few folks are going to jump up and down happily because it's a Universal binary, I have a few other reasons to be happy and one huge one, but we'll save that one for last.

Technorati Tags: Apple Remote Desktop, AppleScript, Dashboard, Installers, Technology, Widgets

Apple Remote Desktop 3 answers one of my biggest gripes about version 2, and that was the insanely silly workarounds you had to deal with to get a file to a single client. Under version 2, to copy a single file to a client, you had to set up a copy task, and run the task. This has changed. In version 3, here's how you copy items to a single client:

1. Drag


2. Drop

Another peeve of mine was reports. With Version 2, reports were always kind of a "Meatcake" scenario:

"Will Apple Remote Desktop reports work today?"
"They worked yesterday"
"But will they work today?"
"We just don't know"

Well, in my testing, reports finally work. Not only do they work reliably, but there's a couple new ones added which, for those of us in a SOX state of mind, should help us get through our audit-ory hells a little easier, namely Application Usage and User History. With User History reports, you get the login/logout dates and times, the the login type, (console or a ttyp number) and the host they were logging in from, localhost or remote DNS name/IP number. It's not like this information was particularly hard to get other ways, but having it built into Apple Remote Desktop is a nice touch for enterprise users, who have far more need for this information beyond reasons of security. In truth, it's a heck of a feature for anyone running a network, enterprise, K-12, Higher Ed, or SMB. It's amazing the problems that can be stopped dead when people realize you can track them, with ease, across a network. (I know as the parent of a 12 year old boy, having the powers of $DEITY$, and him knowing I have them saves me a lot of time by not actually having to actually use them...much)

The Application Usage report is useful for similar reasons. It shows the application, how long it was the frontmost application versus how long it was simply running, which user launched it, the state of the application, etc. While it would be nice to have a feature to collapse multiple launching of the same application by the same user, when you need to track what someone was doing, this is a neat trick. In addition to such draconian needs, it's also a great way to plan upgrades and set priorities. If I see that my users are spending 90% of their time in a given application, then I know that any kind of issues, or reports of issues involving that application need to be taken more seriously. Accurate usage data can be used to help as well as implicate people.

The Task Server, introduced in Version 2 has gained new abilities in Version 3, another benefit to those of us who like to do things after people go home, including the sysadmins. (Yes, sysadmins do in fact like to go home. Shocking, but true) Version 3's Task Server now adds the abilities to perform installations via Apple Installer Packages, collect Application Usage and User Data via the Task Server. While the last two are just an extension of the Task Server's reporting abilities from Version 2, being able to do installs via the Task Server is sweet indeed. Not having to sit there and watch progress bars from the Admin workstation when you have to install large packages to many machines is something that makes any administrator smile.

Encryption of the connections between the administrator workstation and clients has been added for control/observe tasks, text chats, sending text messages, Send Unix, Open Application/Items, Empty Trash, Set Startup Disk, Rename Computers, Sleep/Wake, Restart/Shutdown, Logout, and both file and package copying tasks. So, for those working in environments where unencrypted data connections are a bad thing, (which should be, well, everyone), Apple Remote Desktop allows you to handle these tasks more securely than before.

For those who don't like applications that try to take up all of the bandwidth, Apple Remote Desktop 3 allows you to specify an upper bandwidth limit for copying files and packages. if you're on a large network with lots of Macs, this can be an issue, especially if others on the network have the silly idea that they should be able to get work done even when you're using Apple Remote Desktop.

If you're into Dashboard, there's an Apple Remote Desktop observation widget that you can use to look at one client at a time. This can be good if you have one client you need to keep tabs on for long periods of time, but don't want to keep hitting the "Observe" button, or leaving that screen up constantly. (It's really handy for the 12 year old too. Hearing the voice of doom suddenly say, "Gee, I don't recall your teacher saying you were starting a unit on the history of Neopets" not only reminds the dear child of what he should be doing, but the mad scrambling you see in the widget is really funny.) Another neat trick is that you can run multiple instances of the widget, and double-clicking on the screen you're observing opens up a control session to that system. Okay, so is it a major feature? No. Is it way cool? Oh hell yeah.

Now, don't get me wrong, all of the things I've talked about are important new features, and I've not hit all of them by a long shot. For a more complete list, you can look at the chart on the Apple Remote Desktop 3 Upgrade page. But there's one feature that is, for me, of great importance, because it makes doing mundane Apple Remote Desktop tasks manually a thing of the past, and extends the featureset of Apple Remote Desktop to one that approaches infinite:

You can now, finally, automate the Apple Remote Desktop application itself. This is a major one, because quite honestly, even if I can copy a file or install something to multiple computers via Apple Remote Desktop, prior to AppleScript, I had to do this manually. Select the computers, select the file, create the task, run the task. If I had to do multiple client management tasks a day, i had to sit there and make with the clickey-clickey for each thing.

A manual administration tool kind of blows.

Well, the suck level of Apple Remote Desktop has dropped like a rock. Now, the way Apple is pushing this is, of course, Automator. Automator rocks, it's way sweet, but, there are things that I can do with AppleScript that Automator's not going to be real good at, such as custom solutions that don't need any kind of user action beyond initiation.

First let's look at the dictionary though, to get an idea of what we can and can't do. Apple Remote Desktop 3 has a "Remote Desktop Suite" that contains the Apple Remote Desktop-specific items. It's a solid first dictionary, (tons better than some of the first attempts I've seen in other Apple applications, like Keynote), although it has a few holes, most notably application preferences and reports. Not being able to script applications preferences is an annoyance, as being able to script the preferences settings can be handy, especially if you're setting up a new administrator workstation. Not being able to automate Apple Remote Desktop reports via AppleScript is one of those "But reports beg to be automated" kinds of things, especially when you consider that scriptable reports would allow you to run the report, then dump it into another application for post-processing. Yes, there are ways around this, but then your report workflow starts to get more complex. Even if I could only automate the saving of scheduled reports, that would be something. Hopefully, this will show up in the next major release.

Another limitation is that scripting the adding of new machines to the "All Computers" list is not something you can just do, because you can't set up the authentication parameters through AppleScript. This can be good or bad depending on your POV. I find it to be more of an annoyance than anything, but there are ways to work around this limitation, just not via Applescript.

A bigger annoyance for me is that most of the properties of a computer or a computer list are read-only. This forces things like changing IP addresses, DNS names, etc., to be manual You can't get the contents of the Apple Remote Desktop information fields either. Not crippling, but annoying.

While you can get the selected computer, you can't get the selected computer list, which is just silly to me. So to target the list you're currently looking at, you can't just say "set theList to the selected list" or some variant. I found this to be really annoying, because it makes me have to either hardcode list names into my script or present selection dialogs, neither of which are good for flexibility or automation.

There's also a curious bug that shows up when you're trying to get a list of all the copy file destinations. If you run the following code, you'll see what I mean:

tell application "Remote Desktop"
     set theDestinationChoiceList to {applications folder, current users desktop folder, current users home directory, same relative location, specific folder, system folder, system fonts folder, system preferences folder, top folder of the boot disk}
     set theDestinationList to choose from list theDestinationChoiceList with title "Select the destination for the file" with prompt "Pick the destination for the file(s)" without multiple selections allowed
end tell

Instead of getting a list of names, like "applications folder" you get the four letter codes for the folders, like "apps". It's a formatting issue more than anything, but it's something to be aware of. (yes, I've filed this as a bug with the Apple Remote Desktop team)

But even with the limitations of the dictionary, and sometimes odd list formatting, Apple Remote Desktop 3's scripting is more than adequate. For one, you can automate almost every management task that Apple Remote Desktop can perform. The syntax for doing so is a little obtuse, and I think the folks on the Apple Remote Desktop team who set up the dictionary should have talked to the core AppleScript team a little more about class names. (Come on guys, set network startup disk task as a class name? It's a little much.) Running the tasks is a two-part process. First you build the task, so for example, to create a Send unix command task, you have:

set theTask to make new send unix command task with properties {name:"Get boot drive root listing", script:"/bin/ls -ale", showing output:true, user:"root"}

(Since Apple Remote Desktop as to be able to do things regardless of any console login, you do a lot of stuff as root.)

To run the task, you use the execute command:

execute theTask on computer list "Admin Macs"

That's the basic procedure for pretty much any task. Define the task, execute the task on a computer list or computers. The Remote Desktop Suite has only seven actual commands:

• add, for adding a computer to a list or task


• control, for initiating a control session on a specific computer. (note that you could iterate through an AppleScript list to start multiple control sessions if you want with this command)


• execute, which, as we just saw, executes a task on a computer, list of computers, or computer list


• observe, which allows you to initiate an observe session on a computer or computer list


• release, to terminate a control or observe session
• remove, to remove a computer from a task or computer list


• stop, to halt a task

By adding AppleScript support, Apple Remote Desktop has given me an insanely cool feature, namely the ability to use folder actions with Apple Remote Desktop. For example, when updates become available from third parties, instead of having to manually initiate the install, I just implement a folder action. Drop the installer in the folder, and the folder action script deals with it for me. The task server makes this even cooler, since I can drop the installer on a local folder, and have a script that runs the install from the task server. I don't have to do anything else. I have a set of messages that I send out on a fairly regular basis, "Please log out when you go home, updating the server", "Please reboot your machine when you get a chance", etc. Write up a folder action and use some text files with the right message in it. Drag, Drop, done.

If someone has an application crash, I can set up a folder on their desktop where they can save the crash report. They drop the report in, and kick off a script. The script runs system_profiler, and then creates a tarball with the profiler report and the crash report, then copies it off to me with the computer name and date as the name. The folder it ends up in has another folder action attached to it that reads the file name, and puts both into a (non-ARD) report for me, with the name of the computer as the report name. I can then run an Apple Remote Desktop report to get more information off of the system if I want. If I could script reports, then I could do this automatically too, so what I would get would be a more complete picture of the machine, including Application usage for say, the last month. Being able to tell when an application started crashing is A Good Thing.

That's why I'm excited about AppleScript. In a lab situation, if someone's having problems with a project, rather than having to get the instructor's attention via the menubar widget, wait for the screen sharing to start, and then get helped, they could use a folder action that would take the problem file(s), send them off to the instructor, open them on the instructor's system and start a screen sharing or observation session, so the instructor gets the problem notification, the connection to the student, and the problem files at pretty much the same time.

It's the ability to tie all kinds of processes into Apple Remote Desktop via AppleScript that make Apple Remote Desktop 3's dictionary so valuable, so cool, and for me, one of the top two or three, if not the top reason to upgrade. Quite honestly, automation alone is a compelling reason to upgrade. When combined with the rest of Apple Remote Desktop 3's new features, it's a no-brainer.

With version 3, Apple answered a lot of requests, fixed some long-standing issues, and added not just a lot of new features, but new features that are useful. Sounds like a worthwhile upgrade to me.

Comments

February 9, 2006

Script Debugger 4 is available! If you do any kind of serious AppleScripting, (or even JavaScripting with the OS), you need this. Late Night Software pwnz!

Go now my minions, fly, fly like the evil monkeys you are and buy...er...wait, note to self, don't post while reading Wicked. But go buy a copy if you're an AppleScripter, it's "Teh B0mb".

Technorati Tags: Apple, AppleScript, Mac OS X, Programming

Comments