AppleScript Drop-down Menu Hangs when Connected via AFP

We have run into an odd issue with the AppleScript drop-down menu hanging when the some users have an active AFP connection to our old Xserve. So far, I’ve narrowed it down to the SystemUIServer process hanging. The process sits idle, then increases to almost 15% CPU usage, taking 10-20 seconds before actually displaying the drop-down menu. Some users report that the menu never loads unless the AFP connection is disconnected, or the SystemUIServer process is force-quit via Activity Monitor.

Is this a known issue, or one that affects others? So far, I haven’t found any useful info. Unfortunately, with the new Mavericks UI scripting environment, there are some scripts that we must run from the drop-down, and many of the files we are processing live on that Xserve. We’re planning on moving to a new ExtremeZ-IP server later in 2015, but it would be nice to find a practical solution or even a workaround until then given the number of artists and designers affected.

Hey There,

Apple’s AppleScript menu is something I would never use.

Try FastScripts, and see if it overcomes the problem.

I’ve used it since 2003.

The dev was an Apple Engineer long ago and has been an active freelancer for a long time now.

Hi Chris.

[OT] Just out of interest, does FastScripts allow application scripts to be listed below general ones yet? I gave up downloading demo copies years ago.

Unfortunately, it looks as though the drop-down functionality of FastScripts mirrors the bug we’re seeing with the default drop-down menu. Both hang either for a short period or indefinitely, with the SystemUIServer process hanging, though FastScripts seems to hang indefinitely when the default menu eventually drops down on some Macs.

It sounds a bit like something in one or more of the scripts is trying to find something on the network. I assume the scripts are all local. Could they have properties that refer to something on the network?

Hey Nigel,


A) Why would you want them to be?

B) Have you ever asked Daniel to implement that feature?

It’s so far superior to Apple’s AppleScript Menu that I don’t understand why more people don’t just pony up the $9.95 US dollars for it. For that matter the free version has 10 available keyboard shortcut and is otherwise un-crippled.

The fact that it makes creating global and app-specific keyboard shortcuts for AppleScript and shell scripts simple sold me after using the demo for a day back in 2003.

Even though I use Keyboard Maestro for most of my automation needs, I still use FastScripts to run most of my scripts - because it makes managing and editing them easier than does KM.

Hey There,

Default drop-down menu? Oh, you mean Apple’s AppleScript Menu I suppose.

This is telling you that something is at fault other than the AppleScript-runner mechanism (probably).

That kind of problem is really hard to diagnose without having hands-on.

That’s where I expect them to be. :slight_smile: Applications scripts went below general scripts in Leonard Rosenthol’s OSA Menu back in the days of Mac OS 8/9 and I got used to the arrangement then. It also has the advantage that any particular script in the menu always appears in the same position on the screen, so I can use muscle memory as well as eyesight to select it quickly. When application scripts go above the general ones, the general ones’ positions move up and down according to how many scripts you have for the current frontmost application. Not helpful.

Daniel’s original incentives for writing FastScripts, as I recall, were his conviction that application scripts should appear above the general ones in the menu and the then current problem that the Script Menu in Jaguar didn’t return focus to the user’s frontmost application. The focus problem was cured in a later Mac OS version and Script Menu also acquired the option to let the user choose which way round to have the menu. FastScripts, on the other hand, lost one of its raisons d’être and stuck rigidly to the menu order I didn’t like. Its ability to run scripts using keyboard shortcuts was of no interest to me (what’s the point of having a menu if you’re going to use keyboard shortcuts?) and its reported ability to run scripts more quickly wasn’t enough to make up for the menu order or to justify a financial outlay. So I’ve stuck with Script Menu.

Of course not. I’d never imply to a developer whose software I don’t need that a certain tweak might get me to buy it.

Fair enough. But FWIW, Daniel is the sort of developer who I suspect would appreciate having the rationale put to him regardless of the possibility of a single sale to you. Just sayin’…


I agree with Nigel, when it comes to the placements of the scripts (I prefer the application scripts at the bottom), and I don’t give unsolicited requirements for a product I don’t own.

However, I disagree with the short cut keys. That is a really nice touch. The services with shortcut keys are fare more inapproachable from the Keyboard preferences pane, and they are sort of taken out of the context as well.

It is easier to have the short cuts on the menu, directly assigned from there. I find it ok, to say execute a script once from the menu, and then use the shortcut, if I am to execute it repeatedly. Or just assign a shortcut key to it, when I find it to bothersome to click on the script menu, find the script, and click again to execute it.

There is definitively still a place for FastScripts, and I hope some of you guys, who would like to FastScripts to list the other folders above the Applications scripts, and do own it, to post Daniel Jalkut of Red Sweater Software the idea.

Great guy Daniel Jalkut, who shares his ideas.

Hey Nigel,

I too used OSA Menu many years ago, although I’d forgotten it placed universal scripts above app-specific ones.

What’s the point?

A) Quick access for editing a script or revealing it in the Finder.

B) A keyboard shortcut that opens the menu and allows for type-selecting a script. (Fast muscle-memory driven operation.)

C) The same keyboard shortcut allows you to quickly review keyboard shortcuts of the scripts if memory falters.

D) Very quick access for changing keyboard shortcuts.

  • I almost never mouse the FS menu. I use the keyboard shortcut to open it and navigate with the keyboard.

Hi everybody! Thank you for including FastScripts in your spirited debate about the pros and cons of various script management/execution utilities :wink:

Nigel, I had never carefully considered the possibility that some people would honestly prefer the application-specific scripts at the bottom of the menu. My bias was always strongly towards having them at the top because it seemed to me that the scripts tailored for the active application would be the very ones you’d be most likely at any time to want to run. So I was confused by the behavior of OSA Menu and Apple’s Script Menu after it, beause it seemed cumbersome to have to open the menu and then scan past all the global scripts to get to “the good stuff.”

So I am enlightened to hear your good arguments for favoring the scripts staying at the bottom. I can see how muscle memory for clicking specific scripts always at the same position in the menu would be a strong argument for that. I am also biased in that I don’t use the menu all that much, preferring to use keyboard shortcuts for the stuff that I run “all the time.” So probably that takes the place of those scripts whose offsets I would otherwise memorize with my finger-muscles.

I would encourage anybody who has the idea that an application is “almost useful” to send feedback to the developers whether you’ve purchased the app or not. I would guess that most of us are happy to know that people are using and thinking about our software, even if it’s only to think that it doesn’t have any use :wink: Nigel, in your particular case it sounds as though the other features of FastScripts are also not very alluring, so perhaps the tweak of application scripts placement wouldn’t be a game-changer, anyway.

Getting to the point of the original poster in this thread, since it was mentioned that the problem also affects FastScripts, of course I’m particularly interested. I saw that AFP mounts were involved, which leads me to wonder if the problem isn’t rooted in some alias to an AFP volume being present in the local Scripts folder. I’ve seen some pretty crazy things, for example an alias to a … a whole AFP volume or large subtree? Could cause an app such as as FastScripts or Apple’s Script Menu to assume the whole folder is intended to contain scripts, and it would scan the whole thing laboriously in order to be build an accurate list to convey in the menu. It might explain that the issue only occurs when the AFP volume is mounted, because when it’s not mounted the alias would probably not resolve and thus not present dozens, hundreds, or thousands of files to the script menu as considerable for inclusion in the menu.

Hope this helps, if anybody has any other feedback about FastScripts feel free to get in touch any time at


Thanks for following up, Daniel. Yeah, unfortunately, I did notice the same issue with both script menus, so I was simply thinking that I had far too many scripts in my library (found a similar thread here: I had thought about taking the time to archive some of the older ones, leaving only currently used scripts in our active collection (I push this set out to about 15 Macs, updating them regularly).

Here is an example of what i’m seeing when I remove all but a folder or two from the Library/Scripts folder:

I do have aliases in some folders pointing to the archive location on our server, via an AFP connection. Next I’ll test removing the aliases to see if it makes a difference. Thanks for the advice.


UPDATE: Don’t put aliases to AFP shares in your Library/Scripts folder! Well, probably not, but that was the issue in my case. I had aliases to archives, samples, and other server locations in my script collection, and removing them restored the prompt drop-down menu. No more pinwheel of death! Woohoo!!! Thanks for everyone’s advice and insight!

That’s great to hear that the AFP alias was the culprit!