The macosxhints Forums

The macosxhints Forums (http://hintsforums.macworld.com/index.php)
-   OS X Developer (http://hintsforums.macworld.com/forumdisplay.php?f=27)
-   -   Need script to monitor an entire directory (http://hintsforums.macworld.com/showthread.php?t=73408)

websitewill 06-07-2007 10:36 AM

Need script to monitor an entire directory
 
Hello everyone. This is my first time here. I need a script that I can attach to a single folder that will perform an action when files are added, no matter what subdirectory they are added to. The action to be performed is a simple email, something like 'Hey Bob, a new file is waiting for you' when a file is placed in the Product_Info/Inbound/Bob folder.

What I'm thinking is, a file is added to a folder, I get the name of the folder where the file is added. If the folder name is Bob, I send email to Bob, if it's George, I send to George, if the folder is 'Approval', I send to Rick, Mick and Vick...

The hard part is, this is my first time with a Mac, and with Applescript so I don't really have a clue where to start. I know how to attach scripts to folder actions but I see nothing that allows catching events from subfolders and we really don't want to assign specific scripts to each folder. We want one script to rule them all.

Thanks for any help,
Will

tw 06-07-2007 11:20 AM

well, this is a little tricky, if I understand you correctly. AppleScript folder actions are designed to work only on the top-level folder; a launchd item will notice changes anywhere in the folder hierarchy, but it won't tell you what or where the change is, only that something happened. best suggestion is probably to create a single script - something like this:

Code:

adding folder items to thisFolder after receiving thisItem
        set folderName to name of (info for thisFolder)
        set itemName to name of (info for thisItem)
        -- this gives you the name of the folder, and the name of the added file,
        -- which you can send to an email
end adding folder items to

then attach it to each folder you put in your inbound folder.

now if you've got a lot of folders in your inbound folder (or the folders change frequently) then you can write a script (attaching it to the inbound folder) that will attach the above script to every new folder you put in the inbound folder... meta-scripting, whoohoo! :)

raymondlewisjone 06-07-2007 02:37 PM

Whoooooooooh Whoh Whoh. No way, dont' use applescript. Use a daemon. A launch daemon can be set to run every time a folder is modified. I love using "Lingon" to create daemons. A simple modification to postfix and set up a simple mail server. This turns the whole thing into a invisible process. Applescript would have to open up "Mail.app" and probably would take a long time to run, leaving your computer useless untill it is done. You could have several folders, each with a ".emailaddresses" file (the "." would make it invisible) and a ".list" file. And whenever the folder is modified, it will check the ".list" file for already existing files (leaving only the modified files), then read the ".emailaddresses" file and send the email to those people.

tw 06-07-2007 03:40 PM

Quote:

Originally Posted by raymondlewisjone (Post 384215)
Whoooooooooh Whoh Whoh. No way, dont' use applescript. Use a daemon.

that would work too - don't you think it would be a more complex setup, though?

really, I'm waiting to see what they do with launchd in leopard - if they've made the obvious improvements it will just plain rock.

raymondlewisjone 06-07-2007 04:14 PM

Yeah, it may be a more complex setup. But, just like I tell my fiance (who never matches socks when she does laundry), It might take 20 more minutes to do it at the Laundry-Mat, but it saves me 10 minutes every day when I am looking for @#$!@ matching socks.

I hope you know I am not trying to sound mean, but there are so many things I have found to go wrong with folder actions. If you are doing something else like Emptying the Trash, it could throw up an error saying the Finder is busy (if your script uses the Finder, of course). Of course, i am being stubborn because i just love using the terminal and daemons and StartupItems instead of Applescripts. Don't get me wrong I use Applescript a lot, but I never tell the Finder (or any other app for that matter) to do something that can be accomplished with a shell script.

cwtnospam 06-07-2007 04:40 PM

Quote:

Originally Posted by raymondlewisjone (Post 384215)
I love using "Lingon" to create daemons.

How do you get it to monitor a folder? If I use the 'Assistant', it tells me the script will need to clear the folder when done. I'm assuming that's because it would keep calling the script if it left files in there.

raymondlewisjone 06-07-2007 04:51 PM

Don't use "Assistant", just click the "New" button. Under "Paths" you can set up a "Watch " folder. The script will only run when it is modified, it doesn't have to clear it.

tw 06-07-2007 04:55 PM

Quote:

Originally Posted by raymondlewisjone (Post 384254)
Don't get me wrong I use Applescript a lot, but I never tell the Finder (or any other app for that matter) to do something that can be accomplished with a shell script.

ah, see, I'm just the opposite: I rarely use a shell when I can use applescript (the same way I'd hesitate to use gasoline to start a BBQ grill). to each their own, I guess. :-)

raymondlewisjone 06-08-2007 11:38 AM

well, it just seems like bother to use the Finder to do copying of files, deleting, moving, etc.

You always get that damn progress dialog box, and then your script could possibly time-out while it is waiting.

using shell commands like cp, mv, rm, etc are faster (Activity Monitor).

tw 06-08-2007 12:13 PM

Quote:

Originally Posted by raymondlewisjone (Post 384466)
well, it just seems like bother to use the Finder to do copying of files, deleting, moving, etc.

You always get that damn progress dialog box, and then your script could possibly time-out while it is waiting.

using shell commands like cp, mv, rm, etc are faster (Activity Monitor).

well, we can debate this ad nauseum. I've never had the problems you're concerned about, and the time differences you're talking about aren't humanly significant, though I'm sure they are satisfying. :) Plus, the finder was designed to mange the file system...

so, you're good with unix, and you like it, and that's cool. but let's compare:

unix solution requires
  • one or two invisible files per folder
  • launchd plist
  • a subroutine for cataloging and discriminating between files and folders (meaning you have to run the entire folder hierachy every time to find a new file
applescript solution requires
  • one script (attached to every folder)
now I might go your way and send the mail via shell script to avoid invoking mail.app (unless I wanted to keep a record of the email, that is), but otherwise handling things via applescript is just much simpler. which do you want to recommend to someone who's not as script savvy as you and I?

raymondlewisjone 06-08-2007 02:30 PM

I wouldn't recommend either. I guess I would recommend doing it myself.

Just for kicks, try copying a folder that contains lots of files, folders and sub-folders with a large ".DS_Store" file. Oh yeah, the Finder will say it can't because the ".DS_Store" file is too large. However, I will just run the shell script first and remove it before copying. Not significant. I believe there is a recent "Hint" on the main page that you should check out.

tw 06-08-2007 02:48 PM

ray, who are you trying to convince - me, or yourself? the only criteria for good programming are (a) it gets the job done, and (b) it makes you happy. I think both solutions are functional, but I think the folder action way is simpler and more elegant, and that makes me happy. you're free to disagree.

if you'd like to get in the last word, you can do so, now. ;)

Hal Itosis 06-08-2007 03:33 PM

One interesting difference is that the Folder Action can easily be tailored
to act "on adding" or "on removing" etc. The WatchFolder modus operandi
seems to kick-off the associated script for any change to the folder.

That could be undesirable (or not) depending on one's circumstances.

For example, I was testing launchd's WatchFolder on /Volumes to see
when disks were mounted. The script was simply: "say volume folder
accessed". I expected it to make announcements when any disk was
mounted or unmounted, but it seemed to be triggered by some other
activity. Can't recall exactly, but it seemed like launching certain
programs would scan the /Volumes folder... and that would do it.

The announcement would also occur at mysterious times when it
seemed like nothing was going on. (*Certainly* no volumes were
being mounted or dismounted, and fseventer didn't show any files
created or deleted within the 10 second window I set... so idunno).

I too prefer Bash over AppleScript whenever possible, but launchd
still could stand some tweaking IMHO.

-HI-

PS: here's my plist if anyone wants to check it out:
Code:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
        <string>my.mountcheck.job</string>
        <key>LowPriorityIO</key>
        <true/>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/bin/say</string>
                <string>volumes folder accessed</string>
        </array>
        <key>WatchPaths</key>
        <array>
                <string>/Volumes</string>
        </array>
</dict>
</plist>


cwtnospam 06-08-2007 07:52 PM

Quote:

Originally Posted by Hal Itosis (Post 384540)
One interesting difference is that the Folder Action can easily be tailored
to act "on adding" or "on removing" etc. The WatchFolder modus operandi
seems to kick-off the associated script for any change to the folder.

That just means that your script needs to determine what kind of change took place. Here's one I've been working on:

Code:

#!/bin/sh
cd ~/Desktop/Addresses
ls > ~/Desktop/Addresses/.list1
date >> ~/Desktop/newfiles.txt
diff  ~/Desktop/Addresses/.list ~/Desktop/Addresses/.list1 | grep ">" >> ~/Desktop/newfiles.txt
diff  ~/Desktop/Addresses/.list ~/Desktop/Addresses/.list1 | grep "<" >> ~/Desktop/newfiles.txt
mv ~/Desktop/Addresses/.list1 ~/Desktop/Addresses/.list

All it does is write any new or removed files to newfiles.txt on the desktop. There are more things I'd like to make it do, but right now I'm more concerned with finding a better way to determine which files are added/removed. It seems to me that I shouldn't have to call the diff routine twice.

raymondlewisjone 06-12-2007 11:28 AM

Yikes, sounds like you're trying to convice me. Whatever. To each his own.

I don't exactly know what you mean by "elegant", but OK.

Anyways, everyone but the original "poster" has replied to this topic. Does that seem odd to you?

If he/she were to have replied, I would have written the solution by now.

tw 06-12-2007 11:46 AM

ray, I've decided I like you. :)

raymondlewisjone 06-12-2007 12:33 PM

Do you like me like me, or just like me?

Everything aside, Applescript is pretty cool. I have enjoyed seeing it grow from way back when I used OS9 (Yuck). I have probably built several hundred little apps with it. When I first started learming it, I would try to do everything with it. Now, "Applescript Studio", even cooler. Most the apps I build now are built with it. But, I do use shell scripts whenever I can.

Are you a developer also, tw? If so, what kind of apps do you like?

This might seem a bit forward, but I like you too.

raymondlewisjone 06-12-2007 12:42 PM

Just don't turn into the Cable Guy

tw 06-12-2007 01:37 PM

Quote:

Originally Posted by raymondlewisjone (Post 385427)
Are you a developer also, tw? If so, what kind of apps do you like?

nah, not really. I mean, I could be - I have enough programming experience under my belt - but I prefer the life of a professor. I think that's why I like applescript, actually: I can cobble stuff together quickly without bothering to constructing a GUI, in a relatively forgiving environment. satisfies my intractably lazy side... :)

I will admit, though, I've been having fun with Xcode - very nice little tool. now I just need to find a week free so I can get my head around objective-c.

raymondlewisjone 06-14-2007 09:39 AM

Tell me about it.

I have taken time to learn Applescript, CGI, PHP, Flash Actionscript, and almost all the UNIX commands I want. But I have never taken the time to learn objective-c. It just doesn't seem appealing to me. Out of all of them, it seems to be the least like the English language. I mean, I could probably sit down and figure out anyone's Applescript's just by reading them, but objective-c, I don't think so. Oh well.

raymondlewisjone 06-14-2007 10:33 AM

"professor"?

of what? not "BS", I assume.

Really....of what? I am curious.

cwtnospam 06-14-2007 12:03 PM

Quote:

Originally Posted by raymondlewisjone (Post 385909)
Out of all of them, it seems to be the least like the English language.

I don't know, Unix scripts can be pretty obscure. Heck, because of aliases a script could do almost anything and look like a bunch of jumbled text, or a complete sentence.

raymondlewisjone 06-15-2007 11:05 AM

I don't know what you mean.
What do you mean by aliases?

cwtnospam 06-15-2007 11:33 AM

You can alias Unix commands so that this sentence could contain fourteen different commands.

Try making sense of that if you don't know what the aliases are!

raymondlewisjone 06-15-2007 11:36 AM

Um, what?

Of course, you would have to learn UNIX before diving in.

cwtnospam 06-15-2007 11:48 AM

http://www.uic.edu/depts/accc/softwa.../unixcust.html

raymondlewisjone 06-18-2007 10:11 AM

I repeat, Um, what?

Are you actually bashing the foundation for the Mac OS?

raymondlewisjone 06-18-2007 11:24 AM

Quote:

Originally Posted by raymondlewisjone (Post 386739)
I repeat, Um, what?

Are you actually ***bashing*** the foundation for the Mac OS?

No pun intended.


All times are GMT -5. The time now is 05:51 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Site design © IDG Consumer & SMB; individuals retain copyright of their postings
but consent to the possible use of their material in other areas of IDG Consumer & SMB.