Main

November 25, 2008

Script Debugger 4.5 is out! Let the joyfulness begin!

just in case it comes up

No, it's not free. If free is your only requirement for a software tool, you're stupid, and I want you to never read this site again. Script Debugger is an amazing value for AppleScripters, and it's worth every fucking penny.

Comments

November 4, 2008

Since I voted early, and I had to do some work in Pages that would end up being emailed, I decided to correct an annoyance of Pages and Keynote, namely, the inability to send the current document to an email program as an attachment. I mean, Word and PPT have this, why not Keynote & Pages. (Numbers isn't scriptable, so I don't care about that application until it is.)

Turned out to be relatively simple, even getting it to work with both Mail and Entourage. Normally, Mail's broke-ass scripting makes me give up. This time, it worked. But then it's simple enough. I'll post the source below, and a link to the zipfile is here.

They're both compiled data-fork scripts, so they work best in the Mac OS X script menu. Just open up the script folders for Pages and Keynote, drop in the appropriate scripts, and off you go. The scripts check for two possible errors:

1. You don't actually have a document open. In that case, you get fussed at, and the script exits. Open a document ya goof.


2. The document is open, but has never been saved. In that case, it doesn't really exist on the filesystem, so there's no way to get a path to it. Save your work, what, you want to lose it all?

• This only works with the frontmost document. Got ten open? Better have the one you want emailed frontmost, or you'll get some other document being emailed


• I shouldn't have to say this based on the previous caveat, but I'm in IT, I know better. This only sends one attachment per email.


• If you haven't saved in an hour, and made two hundred changes, and run this script without saving first, it's going to send the old version on the filesystem. No, I'm not going to check the dirty status of the file. What am I, your mother? Check your own damned save status.

Source for the Pages versions –

Entourage:

tell application "Pages"
     set theWindow to every window whose index = 1
     try
          set theDoc to document of item 1 of theWindow
          try
               set theDocPath to path of theDoc as POSIX file
               tell application "Microsoft Entourage"
                    activate
                    set theMessage to make new draft window with properties {send attachments to cc recipients:true}
                    make new attachment at theMessage with properties {file:theDocPath}
               end tell
          on error
               display dialog "Make sure you save your document before trying to email it"
          end try
     on error
          display dialog "Make sure you have a Pages file open, or there's nothing to send"
     end try
end tell

Mail:

tell application "Pages"
     set theWindow to every window whose index = 1
     try
          set theDoc to document of item 1 of theWindow
          try
               set theDocPath to path of theDoc
               tell application "Mail"
                    activate
                    set theMessage to make new outgoing message with properties {visible:true}
                    make new attachment at end of theMessage with properties {file name:theDocPath}
               end tell
          on error
               display dialog "Make sure you save your document before trying to email it"
          end try
     on error
          display dialog "Make sure you have a Pages file open, or there's nothing to send"
     end try
end tell

The source for both Entourage and Mail is simple. The first line grabs the window with an index of 1. If there are no windows open, you get an empty list. I could check for that, but then I have to use really different logic for Keynote, (which always has a window, even if there are no visible windows open), and that would be annoying.

We then have the first try block, which is to set theDoc to the document of item 1 of the list of windows we got in the previous line. If that errors out, then we get a dialog, and the script ends. If it works, we dump into another try block, and get the path of the documentation. For Entourage, we coerce it to a POSIX path, for Mail, we leave it as text. (The difference is so each application can find the file when we set up the attachment.) If this errors out, it means we have a document, but it's never been saved, and so has no path. Display appropriate dialog and end the script.

If it works, then it's pretty straightforward. Bring Entourage to the front, make a new draft window and set it to send the attachment to cc recipients, then attach the Pages file.

The Mail version is the same, except for the syntax of the attachment and the new message.

Source for the Keynote Version –

Entourage:

set theDoc to {}
tell application "Keynote"
     set theWindow to every window whose index = 1
     try
          set theName to name of item 1 of theWindow
          if theName is not "" then
               set theDoc to slideshow of item 1 of theWindow
               try
                    set theDocPath to path of theDoc as POSIX file
                    tell application "Microsoft Entourage"
                         activate
                         set theMessage to make new draft window with properties {send attachments to cc recipients:true}
                         make new attachment at theMessage with properties {file:theDocPath}
                    end tell
               on error
                    display dialog "Make sure you save your presentation before trying to email it"
               end try
          else
               display dialog "Make sure you have a Keynote file open, or there's nothing to send"
          end if
     on error
          display dialog "Make sure you have a Keynote file open, or there's nothing to send"
     end try
end tell

Mail:

set theDoc to {}
tell application "Keynote"
     set theWindow to every window whose index = 1
     try
          set theName to name of item 1 of theWindow
          if theName is not "" then
               set theDoc to slideshow of item 1 of theWindow
               try
                    set theDocPath to path of theDoc
                    tell application "Mail"
                         activate
                         set theMessage to make new outgoing message with properties {visible:true}
                         make new attachment at end of theMessage with properties {file name:theDocPath}
                    end tell
               on error
                    display dialog "Make sure you save your presentation before trying to email it"
               end try
          else
               display dialog "Make sure you have a Keynote file open, or there's nothing to send"
          end if
     on error
          display dialog "Make sure you have a Keynote file open, or there's nothing to send"
     end try
end tell

There are a few differences over the Pages versions, all Keynote-related. Since there is always a window, I end up getting a lot of nulls for the slideshow, (aka "document") of the window. So, because I like things simple, I just check for the name. If it's "", then it's one of Keynote's invisible windows, dialogs pop, and the script ends. If it works, then we get the path. If there's no path, the document has never been saved, we get the appropriate dialogs, and the script quits.

The Entourage and Mail bits are the same here, so I'll not repeat them.

As always, change them how you wish, but if you're going to use my source to start, my ONLY licensing requirement is that you keep my name in a comment as the original author.

Enjoy.

Comments

June 4, 2008

Once again, it's time for the "AppleScript is a failed experiment, it must be replaced by <language>" meme.

This time, it started with Daniel Jalkut, and then John Gruber picked it up too, as well as here.

Gruber wins points for his honest, albeit incorrect characterization of AppleScript as a failed experiment. Jalkut tries to weasel around the issue by saying "Oh no, I'm not saying KILL AppleScript, just make Javascript the default. That's totally not trying to kill AppleScript."

Yeah...sure:

Apple is leading the pack in the development of an interpreted scripting language: JavaScript. It’s time to move on. Adieu, AppleScript.

The problem with this latest spasm is that it makes one, really, really, really, REALLY BAD ASSUMPTION:

That's bullshit. Complete, utter, total bullshit, and shows a complete misunderstanding of the issue. The language is immaterial to the reason why there's not more scripting. The idea that somehow, if we change:

tell application "MarsEdit"
set theDocument to make new document
     set the title of theDocument to "Sample title"
     set the body of theDocument to "The language is not the problem"
     set the category names of theDocument to {"Applescript", "Other"}
end tell

to

with (MacOS.appBySignature('MEbl'))
{
     make(_types.document);

     documents[0].send_post_to_weblog();
}

people will somehow all go "OH MY GOD, OF COURSE! IT'S SO EASY! WHY DIDN'T I TRY JAVASCRIPT BEFORE" is inane. To someone who has never even tried to program, both suck, just like every other language sucks when you're totally new to programming, especially if you're not really a programmer. The only advantage to AppleScript here is that for the n00b, they have a slightly higher chance of figuring out what's going on in the AppleScript. The assertion that AppleScript is far easier to read than write is definitely correct. But that's unimportant I suppose.

(What would help me with scripting is if the Applescript sample actually worked, and didn't throw errors when I try to set the body content and categories. I don't script MarsEdit because the dictionary has issues, not because AppleScript sucks. As well, given Daniel's attitude towards things AppleScript and OSA, I don't see a point in pointing out any further problems. Not much use in it is there? Maybe if I start using <language Daniel approves of>, then I'll think about caring about MarsEdit's scripting implementation again.)

But even when you change it to an application with a properly functioning dictionary, the language difference doesn't make it inherently better or worse, it only makes it different.

Different and Better are not the same things

The idea that somehow, pushing people towards JavascriptPythonPerlRuby will make all of AppleScript's problems magically go away is so short-sighted that I wonder if anyone bitching about the language has really thought about the problem at all. See, here's the deal: The language itself does not really matter much.

I know people in the Mac market who would vomit up their spleen if they had to use shit like RPG, yet I can tell you that RPG is a hell of a functional language. The same for Cobol and the rest. This has nothing to do with the language itself, other than "I don't like AppleScript because it isn't <Language or Language family that I like>

Anytime you hear someone saying that a C-like language or a dot language is "better" than some different language, take a look at what they're most familiar with. Chances are, you'll find a fascinating coincidence in the languages they use.

Funny that.

But seriously, scripting is programming, and programming is only simple when you are doing simple things. If you're trying to do hard things, then programming is hard. There's no language that will fix that or change that. Even the lack of a language won't fix that. Really.

In the mid-to-late 90s, I did IVR programming for a few companies in a 4GL, ("Fourth" Generation Language), the Edify Electronic Workforce, that was drag and drop programming. Mostly large-scale open enrollment applications, but one "Apply for a job by phone" application. The only "code" was the typing of variable and cell names. Everything else was dragging cells on a graph.

(Yeah, that's right, I didn't type a fucking LINE of code for any of it, so pardon me if shit like Xcode and IB don't make my panties wet. It still hasn't caught up to stuff I was using over ten years ago. Programming is still being controlled by the wrong mindset, but that's another rant.)

You know what? Complex, difficult tasks were still complex and difficult. I still had to do a lot of hard mental work to keep things straight, and make sure it all worked correctly. I still spent a lot of time optimizing the "code", and figuring out little tricks to make things work. You think dealing with computer input is interesting? Fucking try to do all your coding with a touchtone keypad as your sole input. Now that is "interesting".

Programming is hard, the language has not, does not, nor ever shall make the thought processes required to create good programs easy. If the language made a difference, why don't we have a dozen clones of Photoshop and Maya?

Yeah.

What ends up making a difference is the IDE and the implementation of the language, not the fucking text you type. If you don't have a good IDE and OS support, then there's no language that won't suck balls. Think I'm wrong? Write a big Cocoa App with pico and gcc as your entire IDE for all code, including UI design. Then write one using all the features of Xcode. Tell me which one was easier, even though the language never changed.

The biggest problem with AppleScript isn't the language. The language is fine, as long as you don't start digging a hole with a hammer. (The idea that every language must do every thing perfectly is just fuckin' stupid, and it needs to stop. Fortran is not even close to as good as C for writing operating systems, but if I have to do big math, it kicks C ass.)

The problem is that Apple's AppleScript tools suck. Script Editor only got barely decent starting some time in Mac OS X 10.4. AppleScript has been around since System Fucking SEVEN PRO, yet it took until TIGER for Script Editor to get any serious work, and it still kind of sucks. Oh sure, there's AppleScript Studio in Xcode, aka "ASS" as in "sucks...".

I've tried ASS, but in the end, it's too painful. AppleScript is not a good fit for Xcode, and it shows. You still have constant cases where your project runs fine one day, and then the next doesn't, even though you made no changes. The debugger has no clue as to what to do with AppleScript and it shows. To do anything beyond a really limited set of what Apple feels like supporting, you have to use Cocoa.

Apple's dev support for AppleScript sucks balls too. The last time I called in to use a DTS incident, I was told "No, we don't do AppleScript, use the mailing list". Um...fuck you? Then stop making me pay for them?

So what do AppleScripters do? Well, they eventually figure out that Apple isn't going to update ASS ever, and that if they want good AppleScript tools, you don't go to Apple. You go to third parties, like Satimage's Smile, (prices from Free to $450 depending on what you need/want), and my personal favorite, Late Night Software's Script Debugger. (Late Night acquired FaceSpan a while back, and is turning it from a half-assed ASS clone into one hell of an IDE...I've seen and used early releases...it's what you can do with AppleScript if you devote some time and money to it)

Script Debugger, (Smile is a kickass product too, but I don't use it, so that's the only reason why I'm not talking about it more), is a great scripting IDE with a debugger that works. It is that great IDE and toolset I get from Script Debugger that makes AppleScript a useful tool for me. If I was stuck with Script Editor? Fuck that, I'd have given up on AppleScript YEARS ago.

A well-done IDE with good OS support is what makes a language more or less useful, not the fucking syntax. (Don't even get me started on what passes for AppleScript documentation from non-Apple developers either. That fuckin' sucks ass too. I can count on the fingers of one hand, the number of applications I've scripted with decent dictionary documentation, and two of them were written by Martin Bestmann. Don't bitch about AppleScript when your fucking documentation consists of "read my dictionary that doesn't explain shit and may not work the way it reads". If Apple did that with Cocoa, you'd all have a fucking hissy fit and you'd be right to.)

Here's a better example. You know what's been responsible for making OS and Application automation on the Mac reach a suddenly (starting with Tiger) larger group of people?

Automator

There's no language at all in Automator. ISVs are including Actions with their product. You can write Actions in any number of languages.

If the language mattered, then no one would use Automator, they'd all be pining away for some magic language. "Oh, Automator's cute, but it has no dots! It's not C! It doesn't do everything Perl does! If only it did everything that C and Perl did, with Javascript syntax! Oh, then we could all just script everything with no mental effort at all!"

Again, bullshit. Automator is a (very) limited version of what I was using in the 90s, and it's real close to being what I need to do real work with it. And there's no language. No typing.

Hmm...

Again, if Cocoa had the same shite tool and other support from Apple, no one would use it.

Oh, and with regard to Gruber's bon mot:

AppleScript, as a programming language, is a noble but failed experiment.

Yeah. I don't think that word means what he thinks it means.

If you want AppleScript to be some other tool, it does suck. If you calibrate your expectations of AppleScript correctly, and stop trying to dig a hole with a hammer, it's a damned decent tool, and that's all it has to be. Stop blaming the language for the shit IDE and Vendor support.

Technorati Tags:
AppleScript, WTF?, Programming, No lanaguage makes programming easy

Comments

May 1, 2008

I know I'm reinventing a wheel here, but it took like five minutes, so who cares. Anyway, one thing that makes me bonkers about Apple Remote Desktop is that while I can run Unix commands on a remote machine with it, what I can't do is easily select a machine and just open an SSH session to it.

Well, now I can. Here's the script:

set theSSHList to {}
tell application "Remote Desktop"
     set theComputers to the selection
     repeat with x in theComputers
          set the end of theSSHList to Internet address of x
     end repeat
end tell

tell application "Terminal"
     repeat with x in theSSHList
          do script "ssh username@" & (contents of x)
     end repeat
end tell

It's pretty simple. We initialize theSSHList, then grab all the selected computers in Remote Desktop. (Note...if you have Apple Remote Desktop open, there is always a selected computer as long as there's a computer in the window to select, so this will tend not to fail unless you're pointing at an empty computer. For obvious reasons, it won't work on a computer you haven't added to Apple Remote Desktop yet.)

We process the list of computers, and dump their IP addresses into theSSHList.

Next is to interate through theSSHList, and open a new ssh session for each item in theSSHList.

This won't bring Terminal to the front, by the way. I don't tend to like that, but if you do, then just add an "activate" command right after "tell application "Terminal"" and Terminal will merrily pop to the front.

Put that in your scripts menu and you can now easily pop ssh windows to Apple Remote Desktop computers when you need.

Technorati Tags:
AppleScript, Stupid AppleScript Tricks, Apple Remote Desktop, Apple Remote Desktop Scripting

Comments