Using make and launchd as an alternative to folder actions

Scripting Forums Code Exchange
, ,
#1

Hello.

At least every one that has the developer tools installed has a copy of make installed with it, others can obtain make from various sources.

Make is a program, that will process actions ” shell commands based on rules in a make file. It mainly process according to rules taking datestamps and the existance of files based on suffix patterns you can define yourself.

Together with lauchd, which can send with it, or invoke a command with parameters in a subdirectory, this should cater for very well defined and easy to use file processing within sub directories. You can even use osascript from within shell files that are called from make receiepes and rules.

The other good thing about make is that i takes include files if you specifiy them, so it is possible to leverage upon previous work if you factor out common parts in a sensible manner.

You can of course store the make file that process the items that are to be dropped on the folder inside the folder for easy access to editing and adjusting your rules.

This of course much more cumbersome than buying something that lets you define rules, but it is a way to do it with what is already in place, (make represents a learning curve). But once you master it, it should be as fast to implement further, with tools like lingon, and a make file template at hand. And you’ll end up with rule based folders that are much more reliable than folder actions.

Examples of such folders coming to my mind, are convering mark down language and TeX documents to pdf, and other document based options.

Droplets are also a good alternative to folder actions. Folder Actions, aren’t and never will be that reliable, not the way I work at least, as I always have to many finder windows open. So, it doesn’t matter whether I have an SSD disk or not; events may be stalled within finder at any moment anyways. Using Folder actions and other means to process those events doesn’t work with finder, and if you do, from osascript, then this won’t trip the launchd process as such, since it doesn’t rely on apple events.

This is an idea that I will work with in the future.

#2

Many of these capabilities are built in to Noodlesoft’s Hazel which I use extensively in place of folder actions. Have a look at that – not free, but worth the $25.

#3

That is a viable alternative to using make at least. It will take you a couple of hours to wrap your head around make, and writing rules. You don’t need to be proficient in shell scripting to use Hazel. But then again if you know make, or how to write a shell script, then you have 25 bucks for something else. And the end result should be as reliable as the effort you put into creating your production script - one way or the other. No reliance of Apple Events. Totally predictable.

What other advanteges Hazel offers, and to a certain extent make offers, over shell scripts, is that you can have a centralized place to view the rules, instead of having to “hop around”. This is one of the good sides of folder actions you loose when you demote the processing level (Make and shell scripts) not hazel, which I am sure is nice and graphical. Nevertheless, it is a good idea to have shell scripts in the folders where you execute them, so you have easy access to what they are doing.

#4

You can find a nice introductory article about make below.

Why use Make

#5

Thanks for the reference – reading it now.

#6

Hello Adam.

When it comes to make, it can be an overly complex tool, so the key to success, is to just disable the usual .SUFFIX rules first, then make you own suffix or pattern rules, and to keep it simple at all times, and dry-run your rules, by issuing “make -n” so you can see what is going on.

If it is just about building one file or two, that is, have a “production line” embededded in a folder, you may just as well use a shell script, that checks the name of the file that is dropped, and takes action immediately.

I am thinking of usage, such as dropping markdown documents onto the folder to produce, and preview html, or having different folders for converting one image type into a resulting one, so that I can have rules for say img, tiff, jpg and pdf, and whatever they are, the outcome will become eps.

Further, with Osa script, there is no problem having the makefile talk to, and pass over files to applications, removing the bottlneck that System Events or Folder Actions is. A make file, also serve as the documentation to how things gets done, which is a nice side-effect, as you can just open it, or preview it from the folder to see what it does.

Osascripts is however nothing I’d consider doing inline in a makefile.

But the clue to using makefiles is to make them (the makefiles) as simple as possible. And find something on the net, than starting off with the 183 pages GNU Make manual, which is really dettering, and a waiste of time, if you don’t build overly complex projects with multiple configurations and platforms.

Maybe xcodebuild can be used the same way, I haven’t checked that out yet.

#7

Thanks for the hints.

#8

Hello. I have made an effort trying to realize this now, it is to be a folder where I can drop applescript files, and have them compiled into scpt files.

I have to stop now, as I "lost the launch Agent, and booting is not an option today.

This is what the property list file looks like, made with lingon.

This is what the makefile looks like, with rules to make a .scpt file from an applescript file. it also works from the commandline, if you enter just “test” for instance, (and not “test.scpt or test.applescript”) or “make all”, then make sees to that all .scpt files are up to date.

[code]<?xml version="1.0" encoding="UTF-8"?>

Disabled KeepAlive Label com.mcusr.osacomp Program /usr/bin/make ProgramArguments /usr/bin/make /usr/bin/make -C /Users/mcusr/Desktop/MakeTest/ all QueueDirectories /Users/mcusr/Desktop/MakeTest RunAtLoad WatchPaths /Users/mcusr/Desktop/MakeTest [/code] The makefile:

[code].SUFFIXES:
.SUFFIXES: .applescript .scpt

SOURCES = $(shell find . -type f -name “*.applescript” )
TARGETS = $(patsubst %.applescript,%.scpt,$(SOURCES))
%: %.scpt

%.scpt: %.applescript
osacompile -o $@ $<

all: $(TARGETS)[/code]
(there are, and must be a tab character in front of osacompile).
I guess I’ll have a nice boilerplate system, once I figure out what errs at this stage, I think my problem is that I have zombie process I can’t kill at the moment.

#9

I can confirm that the above works as I have booted, and loaded the Agent, and it works like it should:

Every time I add an .applescript, it compiles it, when I edit an applescript, it compiles it.

But, the process is executing every 10 seconds, which is not what I wanted. I guess it does this, since I am tracking both the DirectoryQueue and uses the same Directory as a watchpath. I figure I could avoid this behaviour, if I added each file individually as a watchpath to a launch agent, but then the complexity increases rapidly.

Every 10 seconds isn’t that high a toll. :slight_smile:

#10

Hello.

This doesn’t work as I want it to at the moment, either because make touches the make file, or the directory, when it is done processing the rule.

I’ll be back with a solution to this; the obvious being write protecting the makefile. If it is the directory that gets updated by make, then I have to figure out another solution.