bmamlin

Thanks for the link! It wasn't immediately obvious to me at first, but this page points out the likelihood there is some subtle difference in the environment Alfred creates for the script compared to opening a Terminal. I'm invoking a single command using its full path, so it couldn't be a path issue. What could groovyConsole possible depend on that might not be there through Alfred's script environment. Then it dawned on me... the environment! It's probably the lack of a GROOVY_HOME environment variable. I wasn't sure how to post messages from a bash script to Alfred's debugger, so I just added the line "env > ~/Desktop/env.txt" above the groovyConsole command to dump the environment to a text file. Sure enough, my terminal environment defines GROOVY_HOME, but it's not present in the Alfred environment. My GROOVY_HOME variable is set within my ~/.bash_profile, so instead of hardcoding GROOVY_HOME into my workflow, I just added a line to apply my bash_profile. So, now my workflow looks like this: source ~/.bash_profile /opt/homebrew/bin/groovyConsole The first line sets my GROOVY_HOME environment variable and the next line invokes the Groovy Console. And now it works! I was about to give up on it and thought, maybe I could ask the community for some help. All I really needed was a nudge and, with @vitor's help, my workflow is working now! 🙂

UPDATE: Solved with help from @vitor. Running Groovy Console from an Alfred script was failing because the GROOVY_HOME environment variable was not set. Since I use bash shell and GROOVY_HOME is defined in ~/.bash_profile, adding the line "source ~/.bash_profile" to the script set the variable and solved the problem. ______________________________________________________________________________________________________________________________________________________________________ I use Groovy (via Homebrew) and have an Alfred workflow that runs a simple /bin/bash script to open the Groovy Console: /opt/homebrew/bin/groovyConsole I've used this for years without a problem. Now with the combination of Alfred 5, macOS Sonoma 14.0, Homebrew 4.1.16, and Groovy 4.0.15, trying to run Groovy Console with Alfred fails with an error: If I open Alfred's workflow debugger, I get output like this: [18:57:27.690] Logging Started... [18:57:30.009] Groovy[Keyword] Processing complete [18:57:30.019] Groovy[Keyword] Passing output '' to Run Script [18:57:32.262] ERROR: Groovy[Run Script] /Users/username/Library/Caches/com.runningwithcrayons.Alfred/Workflow Scripts/97E732F5-B38A-405B-968B-06714AFF4842: line 1: 92933 Trace/BPT trap: 5 /opt/homebrew/bin/groovyConsole I can successfully run other simple bash scripts from Alfred. For example: osascript -e 'display notification "Lorem ipsum dolor sit amet" with title "Title"' And I can successfully run the Groovy Console from a Terminal window by entering the exact same command from the bash script. In ideas on how I could troubleshoot/fix this?

Assuming you're running macOS 14.0 (Sonoma), it looks like this is Sonoma bug, not an Alfred issue. I've been having the same problem of command-backtick failing frequently and found this thread while looking for a solution. From the discussion on reddit, it seems turning on Stage Manager (Prefs > Desktop & Dock > Stage Manager) may help. Hopefully Apple will fix it soon.

In case it helps... there are tips on importing IPB to Discourse on meta.discourse.org.

Well, I made it a day without the slowness recurring, but it showed up again today. Unfortunately, there wasn't any obvious inciting event (I hadn't just opened something or run something for the first time). It's definitely an issue with using "System Events". This simple AppleScript: tell application "System Events" do shell script "ls" end tell takes several seconds (usually returns instantly). When I loaded one of my more complicated scripts (finding my Gmail chrome tab and switching to it), taking out the call to "System Events" to send "AXRaise" made it run instantly (just not reliably bring the window to focus); whereas, running with the "System Events" call worked but the tab being brought into focus via the "AXRaise" event was delayed at least 5-10 seconds. I tried closing down every app & service and the delay persisted. Logging out and logging back in fixes the problem, so at least I don't have to reboot. I've found some references to people having similar problems (e.g., here and here). Until I can figure out what causes it to happen (other than using my laptop for a day until it "randomly" recurs), I can't reliably recreate the problem and troubleshoot the cause. 😕 Thanks to the Alfred community for helping me think through it. It's clearly not an Alfred-specific issue, just manifesting itself through Alfred since I use AppleScript with calls to "System Events" in some of my workflows. Sorry for filling Alfred's forum with non-Alfred issues (at least I'm not alone 🙂). I've already started to move away from calling "System Events" wherever I can in my Alfred workflows, but I'm not sure how to do things that require UI manipulations (like selecting menu items from a menu bar app that doesn't support scripting or getting Chrome's window to grab focus) without the use of "System Events" in AppleScript.

Some examples: Muting/unmuting Zoom calls Manipulating menubar apps (e.g., getting position of an item to send simulated clicks with cliclick) Bring Chrome tab with Gmail to front (switching to window & tab if I've already got in open somewhere; otherwise, creating a new tab). Most of this doesn't use System Events, but it was delayed, but it does ask System Events to tell Chrome to perform "AXRaise" to ensure it's brought to the front. If I get the delay again, this would be a good one to test if this small step is responsible for the delay. Controlling TiVo, including keystroke simulations to stage the next TiVo command into Alfred's prompt Manipulating position of windows Various scripts to load things into the clipboard (a new UUID, public key, etc.) Looking through my workflows, the above only represents ~25% of what I use, so you're right that most of my workflows don't use AppleScript or, if they do, don't use System Events. While many of the above might be able to be refactored to avoid System Events, they've worked fine for years and – as long as this delay isn't happening – they work just fine. As it stands, it sounds like this isn't a prevalent problem, so hopefully already fixed with recent updates and it won't return. If it does, I'll try to figure out what I'm doing just before it starts and hope to find an offending script or app behind it. In any case, thanks for your help! At this point, at least I know it's not something everyone running AppleScript workflows with Monterey on arm64 is encountering. If it returns, I'll try to do some more debugging.

Yeah, sorry about that. I noticed the problem when I ran my workflow to unmute/mute Zoom calls (uses AppleScript to manipulate Zoom's menu) and it was running ~15-20 seconds after I triggered it. The first thing I did was run the script through the script editor and saw the same behavior (taking 15-20 seconds to execute), which showed it was an AppleScript/Monterey issue and not an Alfred-specific issue. The next thing I did was to create a simple workflow (i.e., run the simplest shell command via AppleScript before posting a notification), so I could more easily test for the condition before joining a Zoom call. When the delay is happening, even that simple workflow is noticeably delayed. Rebooting definitely fixes the problem for a while. Since my last reboot, everything is working as expected without delay. I haven't figured out what makes the delay start happening, but it seems to only be a matter of time before it starts happening again. While it might be an issue with Monterey on arm64, I'm hoping it's a temporary issue with a background service having Monterey compatibility issues (e.g., BetterTouchTool, BetterSnapTool, iStats, etc.), many of which have been getting updates over the past few weeks for Monterey compatibility... and hopefully I won't see it again. If it does re-appear, I'll see if it's only a problem for scripts using System Events (though, that covers most my AppleScript-based workflows).

It doesn’t matter. Anything sent to System Events seems to be affected. For example, in my example above I’m just executing a directory listing (ls command), which should take a fraction of a second, and even that is delayed.

I'm enjoying Alfred on my spiffy new arm64-based MacBook Pro running Monterey (macOS 12.0.1), but started having situations where Alfred workflows weren't responding. Then I noticed they were responding, just taking 10-20 seconds before they would run. With a little more investigation, I discovered these were workflows that use AppleScript (of which I have many). Everything behaves normally for a while, then AppleScript-containing workflows start suffering from this unbearable delay (I haven't figured out what triggers the problem to start). Restarting my laptop fixes the problem for a while, but eventually I end up with delayed workflows again. I haven't rebooted a laptop this often since I was using Windows. I made a little dummy workflow that just runs this AppleScript and then displays a notification, so I can easily test for the delay: tell application "System Events" do shell script "ls" end tell Am I alone in having this problem? I'm assuming it's more of a problem with Monterey than Alfred, but I'd love to know if there's a workaround (other than rebooting).

I've been a heavy user of Alfred for years (thank you!), but recently started re-discovering Alfred Remote while working ... um ... remotely. When I tried Alfred Remote at work a few years ago, the wifi network at work didn't allow devices to see each other, so it never worked. But at home, I discovered I can be watching a Zoom call on my big screen TV (as a 2nd display) and use Alfred Remote to copy screenshots to into Bear, disable my screen saver, etc. right from my iPhone. Sweet! I created a workflow to use on Alfred Remote to mute or unmute my Zoom Audio and, since it's a toggle, I'd like to know whether I've muted or unmuted. I'm currently showing a notification on my laptop, but it'd be even better to show a notification on my phone either with a notification on the phone, a toast within the Alfred Remote app, or being able to dynamically change the icon/text of the remote button (e.g., switch between a mic icon with or without a red line through it like Zoom does). I found a preference setting in Alfred Remote for iOS called "Show command run feedback" but Mother Google didn't yield any details on what this setting might do. I was hoping there might be an option in workflow notification to send a short message to the remote and/or a separate output for this purpose, but haven't found one. I know the remote gives a little feedback in the top right corner "<command name> - OK" to let you know the command was received, but that doesn't help if you've got presbyopia nor does it let you return a status like "muted" or "unmuted". I also know I could create separate commands for mute and unmute, but that wouldn't be nearly as awesome as being able to toggle the icon or show a brief message on the phone. Any chance there's a way to send feedback to the remote that I haven't discovered? And, either way, what does the "Show command run feedback" setting do? I tried toggleing it off and still see the "<command name> - OK" feedback in the top right corner.

I ran into a case where I wanted to copy & paste a little recipe of commands with small changes that varied each time I used the recipe. Rather than making an Alfred workflow for the specific task, I thought it would be more useful to simply copy my recipe and then edit it before pasting. Surely Alfred would help me with that! 😀 A google search for "alfredapp edit clipboard" led me to this thread, but not to the solution I was seeking. So I thought I would share my solution... My solution for this was to use an editor (in my case Sublime Text) that supports editing of stdin. Sublime Text offers a command line option for editing stdin in the form: subl - That will open the editor with the contents of stdin and return whatever is saved from that editor to stdout. All I needed to do was pipe the clipboard into this and then send the output back to the clipboard. That's a piece of cake for Alfred. So, I chose a hotkey (⌥⇧V) to be my "edit before paste" hotkey and linked it to a bash script with this single line: pbpaste | /Users/username/bin/subl - where "username" is my MacOS username. This needs to be have the full path to the subl command (which you can find from the terminal using "which subl". I could get something like "$(which subl) -" or "$(command -v subl) - " to work to avoid having to hardcode the full path. Finally, the output from the editor is passed to a Copy to Clipboard output (with "Automatically paste to front most app" selected). With this workflow, if I want to edit the clipboard before pasting, I press ⌥⇧V, my editor comes up with the clipboard contents, I make my edits & save, and the edited value gets pasted into whatever app I was in when I pressed the hotkey. Voilà!

Okay. Fair enough (I just haven't discovered all the amazing things workflows can do ). I updated the workflow to have Alfred simulate the ⌘V keypress. Now my "Paste and remove" workflow looks much sleeker: (download link) The only "messy" bit is the bash one-liner to remove the most recent item from the clipboard history: sqlite3 ~/Library/Application\ Support/Alfred/Databases/clipboard.alfdb 'delete from clipboard where ts=(select max(ts) from clipboard);' Thanks for your help, @deanishe! This turned out better than I expected. Now I don't need Launchbar's clipboard history any longer and I've got a decent workaround until Alfred adds a native "Paste and remove" option.

Though, I'd happily throw out my workflow in exchange for this feature native within Alfred...

Awesome! That worked. Thanks so much, @deanishe! Locally, it works with a 0.1 second delay, but a 0.5 second delay seems to work more reliably when working in a Citrix Viewer. You can download the Paste and remove workflow from here. Update: I changed the first step to not send an argument and replaced the second step with a simulated ⌘V. I did this because using Alfred's built-in Copy to Clipboard was removing/altering some formatting from clipboard content (underscoring & bulleted lists) in my particular situation of pasting from a Mac into a Citrix Windoze environment.

Thanks for the help, @deanishe! Okay. I thought this was a problem when trying to paste within Citrix Viewer, since it was bringing up a menu instead of pasting. It turns out avoiding the option key (alt key for Windoze in Citrix) is sufficient – i.e., I changed my shortcut key to ⇧⌘V. I copied that from another workflow. I think it was a way of keeping UTF-8 text while removing any associated formatting. You're right, it's unnecessary here. You've helped me simplify the workflow, but I'm still stuck here: So, I can use the paste as provided in the "Clipboard - Getting Started" example and then remove the top entry from the clipboard history, but, despite the item being removed from the history, it's still sitting in the active clipboard instead of being replaced with the next item in the clipboard history. If I try adding the final step of copying the top entry of the clipboard history – {clipboard:0} – to the clipboard, the workflow pastes that to the active application instead of the original item. For example: Type "foo", select it and cut it. Type "bar", select it and cut it. Verify clipboard history shows "bar" and "foo" as 1st and 2nd entries, respectively. Press hotkey (⇧⌘V) "foo" is pasted, is shown as the top item in the clipboard history, is the active clipboard contents. "bar" is gone from the clipboard history. In the last step, I was expecting/hoping it would paste "bar". If I leave off the last step in the workflow, it works as expected, but the active clipboard still contains "bar". I've tried re-ordering steps, but so far I haven't found a way to paste the current clipboard contents and then reload the active clipboard with a different item from the clipboard history. Any ideas what I'm doing wrong?

Well, I've found a workaround using a workflow to "Paste and remove from history". Here's what I've got: My hotkey maps to an AppleScript Run Script that waits for modifier keys to be released (since the paste step simulates a ⌘V, doing so while modifier keys are still pressed can make the paste action fail). The next step is another AppleScript Run Script to paste the clipboard contents. A bash script remove the most recent entry from Alfred's clipboard database. And, finally, the last step uses the "Copy to Clipboard" output to paste the new top entry of the clipboard history into the clipboard so it's ready to be pasted. Wait for modifier keys to be released – Run Script – /usr/bin/osascript (AS) use framework "Foundation" property NSEventModifierFlagOption : a reference to 524288 property NSEventModifierFlagCommand : a reference to 1048576 property NSEventModifierFlagShift : a reference to 131072 property NSEventModifierFlagControl : a reference to 262144 on anyModifierKeysPressed() set currentModifiers to current application's class "NSEvent"'s modifierFlags() -- option if (currentModifiers div (get NSEventModifierFlagOption) mod 2 is 1) then return true -- command if (currentModifiers div (get NSEventModifierFlagCommand) mod 2 is 1) then return true -- shift if (currentModifiers div (get NSEventModifierFlagShift) mod 2 is 1) then return true -- control if (currentModifiers div (get NSEventModifierFlagControl) mod 2 is 1) then return true return false end anyModifierKeysPressed -- Wait until modifier keys are released set anyModifier to anyModifierKeysPressed() repeat while anyModifier set anyModifier to anyModifierKeysPressed() end repeat Paste clipboard contents – Run Script – /usr/bin/osascript (AS) tell application "System Events" do shell script "export LANG=\"en_US.UTF-8\"; pbpaste | pbcopy" keystroke "v" using {command down} end tell Remove most recent entry from clipboard history – Run Script – /bin/bash sqlite3 ~/Library/Application\ Support/Alfred/Databases/clipboard.alfdb 'delete from clipboard where ts=(select max(ts) from clipboard);' Update clipboard with new top of clipboard history – Outputs > Copy to Clipboard (Automatically paste to front most app option unchecked) {clipboard:0}

Could an optional "Paste and remove from history" hotkey be added to Alfred's Clipboard History feature? Sometimes I work with sensitive information that I want to pop off the clipboard history when pasting. Launchbar has this feature in its clipboard history and I've found it very handy. If I'm copying some sensitive information around, I just paste with ⌃⌥⌘V (my chosen hotkey) and know the information will be removed from the clipboard history as it's pasted. I'm aware items can be deleted manually from the clipboard history using fn+delete, but clearing out items manually is tedious and much easier to forget to do. In the meantime, is there possibly a workaround possible within Alfred? For example, can a workflow manipulate the clipboard history? If I could connect my ⌃⌥⌘V hotkey to a workflow that pastes and then removes the top entry of the clipboard entry, it could serve as a workaround. Apologies if this feature has already been discussed/requested. I did some searching and didn't find this specific feature request.

Awesome! Tried it out and it works perfectly. Even better, since you made a separate option for Large Type, I discovered that I prefer keeping Alfred on my primary monitor and just having the Large Type follow the cursor to the secondary display. Great for presentations! While checking it out, I also confirmed that the Show Alfred on mouse screen doesn't work with display one under the other bug is fixed too. Thanks! -Burke

The "Show Alfred on mouse screen" option is a great addition ; however, Large Type has not joined the game. Using Large Type with the latest version of Alfred and the mouse cursor (and Alfred's prompt) on a secondary screen, the Large Type displays on the primary screen instead of the mouse screen as expected. Can we get Large Type to display on the mouse screen when the "Show Alfred on mouse screen" option is selected? Thanks! -Burke I'm running OS X 10.8.4 and Alfred v2.0.6 (203).

+1000 I still run LaunchBar (which I had purchased before switching to Alfred) solely for it's clipboard history (to fill the only real gap in Alfred's functionality). A new Alfred clipboard history that can reliably recall my last ~40 clipboard entries (like LaunchBar does) without cherry picking only certain types of content (like Alfred currently does) would allow me to finally drop LaunchBar altogether. I've looked at other clipboard history tools, but they are all too heavy with unnecessary bells & whistles that make them less efficient than LaunchBar's approach.