Jump to content

Alfred Cron: Execute Scripts (and workflows) on Intervals [v1.1]

Recommended Posts

Quite a few people have asked for the ability to execute workflows at certain times. Well, here's (kind of) a solution.


Alfred Cron (note: consider this workflow to be a 'beta' right nowwith will run any bash command on any interval that you define. Now, this means that you can run any script of any kind (to run a python script, you'd just write: python "/path/to/script.py" 'args'). It also means that you can take advantage of the new External Triggers in Alfred. So, if you want to run a workflow in the background at a certain time, then you can as long as there is an External Trigger for that workflow.


Fun idea: if you're decently good at scripting, then you can replace Hazel with this workflow.


You can define cron jobs through a nifty little GUI box. Just, see it in action in the GIF below:



More detailed documentation is available at http://shawnrice.github.io/alfred-cron.


Download it from Packal.


Note: Alfred Cron uses the Alfred Bundler framework, so when you first execute the workflow, it will take a moment to install the bundler, Pashua, BashWorkflowHandler, and Terminal Notifier. So, be patient at first. They need to download only once.


Also, Alfred Cron makes use of Ctwise's brilliant SetupIconsForTheme, so the workflow will adjust to your Alfred whether it is light or dark.

Edited by Shawn Rice
Link to comment

I do like the idea :)

It's funny how Alfred is just becoming an overlay of my terminal (with the niceness of the instant feedback but without the dynamism of some scripts).


And the dynamism is the perfect part.


Do let me know if anything breaks. It's been working fine on my end, but since it is finicky by nature (I mean, it launches a daemon that I wrote in the background), I expect that it might break outside of my use-case testing.


Also, how much demand is there for actual "timed" events? Let me know below.


And if anyone comes up with great uses for this thing, then please share those as well.

Edited by Shawn Rice
Link to comment

I got it working. I had to uninstall and reinstall twice. Not sure what the problem was. I let the prompt show for 15 minutes while I ate lunch and it still did not work until re-installing the workflow.


Glad you got it working. The email came through while I passed briefly through a strange place with cell service while on the subway, and I was trying to think of what might not be working. If you weren't connected to the internet when you tried at first, then the bundler probably wasn't downloading and started to throw errors (I need better error checking for that). As of now, the any output that the scripts produce should be logged in the, well, log file.

Link to comment

yea, I thought you might have a log file after I deleted it the first time  :). But, since it is now working, I bet your surmise is correct. I have been having weird site blockages from my ISP that do not make any sense (in Thailand and they monitor net traffic a lot).


You might add the sub-title of "Loading resources..." to help people to be patient. Doesn't always work, but worth a try.

Link to comment

Update: Version 1.1



There should be informative error handling to deal with what @raguay ran into. Now it will give you a notification when downloading the backend files, alert you when it's done, and relaunch the cron through an external trigger. Also, you'll get an AS dialog letting you know if you aren't connected to the Internet during setup (two methods to check: (1) ping test, (2) curl test in case icmp is blocked on your network — figured this out when testing on an unexpected network today).


The script filter should give leaner feedback now.


There is a Launch Agent that you can install directly from Alfred; then you shouldn't need to worry about starting it up again (unless you intentionally shut it off).


You can get quick access to the log via quicklook (via Alfred).


Also, everything has an external trigger, so if you want to control cron from somewhere else, then feel free.


The download links are the same.


I have a few larger changes planned, so I'll fix anything minor along with those.


Again, let me know if anything breaks.




# Changelog
* Added LaunchAgent
* Altered all script paths to work with Agent
* Added registry/punchcard maintenance
* Altered initial setup to test for internet connection
* Broke off setup script into first-run
* Refactored code for easier extension
* Changed Cron timing for more accuracy
* Changed runtime checking for more accuracy
* Changed log phrasing
* Added ability to view log easily from workflow (quicklook)
* Made arguments more granular
* Added External Trigger for adding cron job
* Added External Trigger for script filter
* Added External Trigger for script action
* Altered daemon control to give precedence to launchctl
* Fixed infinite loop on startup
* Added notifications for installation and error reporting
* Added invocation of cron after installation
Link to comment

Actually, can you look to see what is in the bundler directory?


~/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries


Under it there should now be three key folders:





Are they there?


If so, could you just try deleting the bundler directory and running the workflow again and see if that fixes it?

Link to comment
  • 2 months later...


Thanks for the incredibly useful workflow. However, I'm having a few problems.

First, when I create a cron job with `osascript "link/to/script.scpt"`, the file created in `~/Library/Application Support/Alfred 2/Workflow Data/alfred.cron.spr/scripts/file` is this single line:

#!/bin/bash\nset -o errexit\nosascript "link/to/script.scpt"

Instead of creating line returns at the \n's, it's putting it all on one line, which doesn't work as that line is commented out. This is fixable by manually editing the file, but still a problem.

The other problem that I'm experiencing is that I can't edit the cron jobs using the built-in editor/creator tool. When I select a cron job from the list in Alfred, nothing happens, but this is logged in Alfred's workflow debugger tool:

[ERROR: alfred.workflow.action.script] Code 127: script.sh: line 73: /Users/Caleb/Library/Application Support/Alfred 2/Alfred.alfredpreferences/workflows/user.workflow.360CC9C8-78BA-4E04-A156-E7E4B63CCCE8/manage.sh 'edit' 'test' '/Users/Caleb/Library/Application Support/Alfred 2/Workflow Data/alfred.cron.spr/scripts/test': No such file or directory

The script "test" does indeed exist at that location. Any ideas?

Link to comment

Actually, the cause of the second problem *might* be that the path to the file is not being escaped where there are spaces in the directory names.


That problem was one that always plagued me (I ended up putting a space in my regular path to catch this on my own), but I'm not sure if that's the case here.


The \n should be there: kind of. Pashua adds in a strange [return] break (or something like that) to indicate new lines. I suspect it does so in order to handle text areas as a single string, but the workflow scripts should be replacing that with \n when writing the script to a file and then reverting when trying to edit the file, but something isn't quite working for you. On that note, what OS X are you using? Next, are you using the most recent version of Alfred Cron from Packal (should be 1.1 -- I think)? Lastly, are you using Alfred v2.3?


I'm a bit busy today and possibly tomorrow, but I'll look into this as soon as possible. I just upgraded to Yosemite, and it looks like something in that might have broken the way that Alfred Cron runs for me (initial suspect is the launchd file).

Edited by Shawn Rice
Link to comment
  • 2 weeks later...
  • 3 months later...

Hi there!

I just love the idea of cron, how it looks and responds in Alfred. But I can't seem to get it to work. I'm running Mavericks 10.9.4 and Alfred 2.5.1


I'm trying to get cron to execute an applescript file using this line in cron:


osascript "/Applications/AppleScript/TinasScript/ThingsApplescripts/AutomatiseradeScript/helloworld.scpt"


Nothing happens. The log file claims that it's running the script every 120 seconds (which is   display dialog "hello world"    so I belive I'd notice if it did ;) )

Also I cannot edit the cron jobs. I changed all file and folder names so that there are no spaces, except for system folder like Application Support etc. Alfred gives the following debugging message:


[ERROR: alfred.workflow.action.script] Code 127: script.sh: line 73: /Users/tinaw1/Dropbox/AlfredSync/Alfred.alfredpreferences/workflows/user.workflow.C96363A1-AFF1-41A7-ADC9-34EC575AE2FE/manage.sh 'edit' 'autoclean' '/Users/tinaw1/Library/Application Support/Alfred 2/Workflow Data/alfred.cron.spr/scripts/autoclean': No such file or directory


The file is there, of course. Any suggestions?

Link to comment

There are few possible problems...


(1) Accessibility Issues

(2) Gatekeeper

(3) Bundler Errors


(1) So, for the Accessibility Issues. Alfred (and maybe bash) need to be able to run scripts with accessibility settings. This change in Mavericks so that you have to authorize applications to do certain things. Open a terminal and just type:

osascript "/Applications/AppleScript/TinasScript/ThingsApplescripts/AutomatiseradeScript/helloworld.scpt"

If it doesn't work, then you might have to authorize some applications. Try opening System Preferences -> Security -> Accessibility (I'm running Mavericks so the path might be slightly different). If Alfred and Bash are there but not checked, then you'll need to check them.



(2) Gatekeeper is this good and annoying thing in which Apple blocks unsigned applications. Two applications that cron uses (installed into Alfred's Application Support folder) are unsigned, and they're unsigned because, well, they just are, but that means that OS X might not let you run them.


So, first, see if this file exists: "~/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries/assets/utility/Pashua/default/Pashua.app"


If it does, then double-click it. If you get an error message saying that the script hasn't been authorized, then you'll need to authorize it. Go to System Preferences -> Security -> General. You should be able to authorize those applications from there without having to mess with the stupidly messy command line utility `spctl`.


(3) If the first two do not resolve the issue, then try deleting the folder "~/Library/Application Support/Alfred 2/Workflow Data/alfred.bundler-aries" and run cron again. It'll re-download the bundler. Cron is still using v1 of the bundler, which is less reliable. When the final push is made for v2 of the bundler, then I'll fix up cron and things should work a bit more smoothly.


Let me know if any of those fix it.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...