Folder Action Setup - triggering the script

(Lenny Eiger) #1

I’m frustrated. I created a Folder Action script. I tested it and it does what it’s supposed to do - basically shortens a file name down to 31 characters. It performs properly in SD using the Execute menu on the Script menu.
However, I can’t get it to trigger…
I’ve checked permissions, I didn’t see a launchd file in Launch Agents, so I made one with LaunchControl. (It says the Folder Actions Dispatcher doesn’t understand the “tick” variable. (command is: /usr/bin/osascript -e “tell application “Folder Actions Dispatcher” to tick”)
I’ve done the Folder Setup numerous times… in multiple ways.
Can’t buy Hazel, cause its for a customer with 20 computers.
What am I missing here… it should just work. Was running Sierra, now running High Sierra… What gets this to actually get triggered?


(Shane Stanley) #2

I’m not surprised — I don’t know of any tick command.

You shouldn’t need a launchd file. You should just attach the action to the folder.

(Nigel Garvey) #3

ASLG still says that folder action scripts have to be in a “Folder Action Scripts” folder inside either the user or local “Scripts” folder. It gives two different locations for the Folder Actions Setup application, which are both wrong on my Sierra machine. (Should be /System/Library/CoreServices/Applications/.) Folder Actions Setup is apparently scriptable, but its dictionary’s identical to System Events’s Folder Actions Suite, so the latter application, being faceless, may be preferable for scripting purposes.

Here’s an example script for attaching an action to a folder:

set thisFolder to (choose folder with prompt "Choose the folder to which you want to attach the action." default location (path to desktop))
set thisScript to (choose file with prompt "Choose the action you want to attach to the folder." default location ((path to scripts folder as text) & "Folder Action Scripts:") as alias)

tell application "System Events"
	set folder actions enabled to true
	-- Only one 'folder action' can be attached to any one folder at any one time, but each may contain one or more 'scripts'. It's the scripts' folder action handlers which are triggered, not the scripts themselves. So a single script may contain different handlers for different triggers or you can have several scripts.
	-- The folder path specified when creating an action can currently be either an HFS path or a POSIX path, BUT the value actually set is a POSIX path without a trailing slash — which is revelant for any script which may test folder action 'path' values.
	set thisAction to (make new folder action at end of folder actions with properties {path:(POSIX path of thisFolder)})
	-- Only the script's name is specified as it's assumed to be in one of the (~)/Library/Scripts/Folder Action Scripts/ folders.
	make new script at end of thisAction's scripts with properties {name:(get thisScript's name)}
end tell

But I don’t know what the situation is in High Sierra.

(Shane Stanley) #4

Folder Actions Setup is in the same place as in Sierra.

(Lenny Eiger) #5

Thanks everyone for responding. I spent hours and hours doing every possible option I could think of to get it to rename a file, but it just wouldn’t. That was the problem the whole time. I thought I would see the telltale flash of a script running… but no. It was triggering. My bad…
It just wasn’t renaming… no matter what I did. It’s the simplest AS one could find - but it wouldn’t do it, no matter what I tried.
Finally I just used “do shell script mv - f both filenames”, etc. and it worked perfectly…

(Nigel Garvey) #6

It’s hard to tell without seeing your script why the renaming doesn’t happen. A folder action script will simply fail silently if an error occurs unless it contains code to trap and report the error.

One thing to check would be to make sure you’re treating the ‘after receiving’ parameter as a list, not just as a single added item.

Something I should have thought to mention before is that when an item in a watched folder is renamed, the appearance of the new name in the folder fools the system into thinking another item’s been added or removed, so any ‘adding folder items to’ or ‘removing folder items from’ handlers in scripts attached to the folder are (re)triggered. This doesn’t necessarily stop them from working, but could obviously cause problems in some cases.