Re: last modified file - how to catch?
Re: last modified file - how to catch?
- Subject: Re: last modified file - how to catch?
- From: Shane Stanley <email@hidden>
- Date: Mon, 07 Jul 2014 22:17:51 +1000
On 7 Jul 2014, at 7:25 pm, Christopher Stone <email@hidden> wrote:
> Oh, you mean like .app packages.
Yep -- directories that appears as files.
> Yes those will have the problem you describe, but that's easily overcome with a filter.
Yes and no...
>
> Is there a list anywhere of standard package types other than .app files on OSX?
No, there's not -- any app can declare that it saves package files. I suppose the info can be extracted from a Mac's launchd database somehow, but it's not a fixed list. Things like .rtfd and .scptd are probably the most common apart from .app, but there are plenty of others. Heck, there's also .osax. They seem to drift in an out of favor.
I'm really not suggesting the ASObjC method because it's better looking or anything -- the Finder code looks like decent AppleScript should, more or less, and in an ideal world it would do what it says on the tin, end of story. But we know it's slow, and likely to result in errors if a lot of files are involved. Even then, someone could use if for lots of simple cases where it would work fine. I've used similar myself often enough.
Similarly, the shell version is very fast, if on the cryptic side, and would probably work fine in most real-world cases where a scripter is trying to discover the most recent file. And if people use ls and then tack the names returned on to HFS paths and don't convert any colons to slashes, that will probably work too, because most people avoid slashes in filenames in the first place.
But both cases are code that works sometimes, and that's problematic unless you are keep the limitations in mind. Use them a lot, or blindly, and you risk errors.
The ASObjC code is also limited -- to the OS it runs under -- but otherwise I suspect it's pretty reasonable (yes, it could do more error-checking). That's not because it's particularly clever or well written, but rather because it's effectively calling Objective-C code that almost every other application uses in one way or another. So if that side of it has a problem, it will be noticed by a lot more than just a handful of scripters. As a bonus, it's pretty fast, because obviously the main users of the underlying APIs need that.
Now given that if you're running Mavericks you have a choice of the three, it seems to me that the little extra set-up time of the lib method is worth considering for the sake of reliability. The cons are that it also takes a little more effort when distributing scripts, and to most scripters it's a bit of a black box -- I'm sure the amount of code puts people off.
Everyone gets to make their own trade-offs, but it helps to be aware of what they are.
--
Shane Stanley <email@hidden>
<www.macosxautomation.com/applescript/apps/>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden