RE: IPTC info
RE: IPTC info
- Subject: RE: IPTC info
- From: "Stockly, Ed" <email@hidden>
- Date: Tue, 7 Mar 2006 17:59:28 -0800
>>>Sorry I seemed to upset you. I think you'd be most impressed by the power and ease of the tool I suggested, and I'm 100% positive it's in scope of this list, but I'll avoid stepping on your toes in the future.
Don't be silly: not upset, step all you want...
> > >>>Roger>>>I sent you a detailed response pointing toward another solution; not sure why it wasn't listed here ....
>
Well, I think you now know why I chose not to include it, but just in case...
>>>>There are *daily* posts showing the power available through the integration of APpleScript and shell tools
Maybe I'm the only one who feels this way, but it seems there are way to many "anything but AppleScript" solutions posted on this list. IMHO, it drives away new and potential AppleScripters. Nearly any question is answered with a flood of shell scripts, perl script solutions when there are perfectly good traditional AppleScript solutions. In this case the poster specifically asked for an AppleScript solution and that's what I gave him.
>>>>> It's just an app, there's no other scripting language to learn.
It's definitely more complicated than that.
Have a look at this example:
set exifToolPath to "/usr/local/bin/ExifTool"
tell application "Finder" to set theResult to the selection as string
set exifToolPath to exifToolPath & "/exiftool"
set EXIF to do shell script exifToolPath & " " & quoted form of POSIX path of theResult as string
It's not just an App, it's a script that has to run in another app with a do shell script command.
compare that to this:
set myFile to choose file
tell application "iMagine Photo"
set quit delay to 1
import graphic myFile
set myMetaData to exif data of importer 1
close importer 1 saving no
end tell
--And the result is an AppleScript list of records with no text to parse:
exif type:info,
exif unicode:PROJECT RUNWAY -- Bravo Original Series -- "Finale" -- Pictured: (Center) Designer Santino Rice
exif type:exif make,
exif unicode:Canon,
exif type:exif model,
exif unicode:Canon EOS-1Ds Mark II,
<snipped out the remaining 16 records>
(By the way, that script would be much much better if Cal or Jon had had a go at the application dictionary)
> >>>>Think of a command line tool as being very similar to using a third-party Scripting Addition - in fact this is why (I thnk) we see fewer Scripting Additions today, and more talk of command line tools on this list.
>
I disagree on all three counts. Using any scripting addition is far simpler than running a shell script or a perl script, and a well designed scripting addition is seemlessly integrated into the language, there's no comparison. Shell scripts have no dictionary, their results are a stream of text (often incomprehensible), they don't provide decent error trapping, their commands and parameters are often a jumble of letters (code if you will) that must be memorized to use or even understand and their meaning is obscured to anyone not well versed in shell or perl. Don't get me wrong, though, I use shell scripts and one day may even use a perl script, but only as a last resort. If I can do it with AppleScript, that's what I'll use and that's what I'll recommend on the AppleScript users list.
There are several reasons we're seeing fewer Scripting Additions: Apple is encouraging more FBAs (like iMagine) over scripting additions; much of the utility that was once only available through third party scripting additions is now built into the OS; there are several well tested, mature scripting additions that contain multiple commands available from a core group of developers that replace dozens and dozens of classic scripting additions.
Personally, I think we're seeing more talk of command line tools on this list partly because many Unix/Mac OS X converts, with a preference for command line tools, are now participating in discussions on this list, but mainly because as AppleScript matures the AppleScripters who cut their teeth on this list and have used it for many years have advanced in their scripting and computing skills and are now more comfortable with Unix, shell, perl, etc.
The drawback is that this list is becoming less of a source for AppleScript information and more of a source for generic/shell/unix scripting information. At times it's even hostile to new AppleScripters. (See the first couple responses to the original post). The MacScripting list is a perfect forum for Unix/shell/perl scripting solutions. This list was set up so that AppleScript users could have AppleScript questions answered with AppleScript solutions.
>>>I'm not trying to be combative Ed,
Neither am I, we happen to have different opinions, that all...
>
>Also, it's a pet peeve of mine when AppleScript is referred to as "code"....
>>>>Well you can be peeved by that all you want but it's a perfectly common use of the term; this is scripting, and a boddy of expressive commands in any scripting or programming language is referred to as code. Code does not imply "cryptic" in this context.
Actually it does. The word "code," in it's cryptic context, was first used to describe programming languages because of their obscure nature, and rightly so, but it shouldn't be applied to AppleScript, a language designed to be understood by anybody. But you've got a point, everybody does it, so I guess that makes it right.
>>>>I think you'd be most impressed by the power and ease of the tool I suggested
I'm sure it's a perfectly good, powerful, workable tool, but it's not what the user was asking for, which is why I didn't mention it.
And as for its ease of use, I find it's like pulling teeth compared to using AppleScript.
> ES
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden