It’s been interesting having been here a little while and watching as Tiger and Leopard turned some of the more advanced AppleScript users here into UNIX-gurus. I’m seeing more and more answers involving “do shell” rather than AppleScript itself (by that meaning, to simplify, not using “do shell”). I like seeing Nigel’s famous on-liners cleverly done in AppleScript.
This is aimed likely at folks like Adam Bell, StefanK, Craig Williams, etc.–not as an insult or even a complaint, but more as an honest query…where do you draw the line between using AppleScript itself and using AppleScript merely as a way to string-together shell commands?
Mind you, even us “intermediate” users (or maybe I’m a beginner who is always trying to cobble-together intermediate solutions!) are not immune. Because of y’all I’ve been able to do things because of “do shell” that really were not doable in AppleScript itself in any convenient way (or any way at all). But there are times where I have to ask, explicitly, for an AppleScript answer because my personal take is to use AppleScript unless forced to use “do shell” for some reason. For me, those reasons generally are: 1) speed (which is rarely an issue, my scripts run local or overnight via automation) and 2) convenience/simplicity (if dozens of lines of code are replaced by a simple “do shell” then I’m certainly game if it’s easy to understand).
But as a last comment, I’ve found some folks get kinda cranky if they give a “do shell” answer and then have to explain it to death or give the canned “just look at the MAN page!”, whereas most folks are quite happy to explain an AppleScript solution. Some of us are just not UNIX gurus (yet).
For example, I have a utlity that James Nierodzik and MouthofSouron helped me with, plus a few others went over relentlessly that uses hexdump and awk and to this day I barely understand it. Heck, folks picked it apart for days, geeking it out. But then again, there was no choice but to use do shell, it was not doable with AppleScript itself without an extreme speed penalty on an already slow routine.
Anyway, ramblings aside–where do you experts draw the line? How do you decide when to do it in AppleScript versus shell?
I personally tend to utilize shell commands more than some others because thats where my background is. a former linux admin. So to that end I am very comfortable using the shell and can often times solve issues there quicker.
I would say the real benefit of the shell though is thru the power and efficiency. With the core *ix/bsd command base, those added by apple, and thru the use of perl/ruby/etc there is little that can’t be done in the shell.
So really I don’t know. I guess I don’t draw a line, but always try to accomplish my task in the quickest yet easiest and elegant manner. To me that means a lot of shell work.
For those who have only learned AppleScript then I can see how other languages may seem strange and hard to understand. I know it was like that for me when I first started learning AppleScript. Over time though I have pursued learning Ruby, Unix, Perl, Objecive-C, C, PHP, and JavaScript.
I am no expert in any language but after spending time in these other languages AppleScript has become more difficult to use and it usually requires more code to accomplish the same task. I personally write few AppleScripts these days, outside of helping on the forum, preferring to stay in Ruby which has become my favorite language. Scripting applications from Ruby is very simple using rb-appscript and I can tie into Objective-C and Unix just as easy.
So, to answer your question, I use the best tool I can find in my toolbox for the job. The more I learn the more I have in my toolbox to choose from.
Sometimes using AppleScript feels like cutting down a large tree with a hatchet when there is a chainsaw readily available.
¢ if there is no AppleScript alternative
¢ if the AppleScript alternative is GUI scripting
¢ for large copy / duplicate tasks (much faster than the Finder)
¢ for find tasks (much faster than the Finder)
¢ if a single shell call causes much shorter code, unlike multiple calls in a repeat loop. In this case I prefer the AppleScript solution for speed reasons
Thanks for your replies and comments on this subject.
I’m no AppleSript expert, thought I think that I can usually do what I set out to do in it. I have wanted to learn more shell scripting since they put it in, but have not got around to it. When I have looked into it what I have found on the web is often unclear in it’s explanation on how to use it and I have not gotten around to getting a book on it. I know the power of it and have read with interest the posts with shell solutions.
A good example that I see for shell scripting is a post the other day where they were looking for a way to find photoshop files with clipping paths. It seems like a great place for grep or another shell command to search the file for a string, or better yet a pattern, and return the results. This could eliminate the need for opening the file in PS or loading the file into a variable and filtering it in AppleScript.
I would like to find a book or good reference to using shell commands in Applescript. It seems that part of the problem learning it is not necessarily the shell commands, which while cryptic seem straight foreword, but the extra syntax that needs to be added in to them when calling them from within AppleScript.
I think that this is a great subject and would be a good addition to the site and community if those that know how to use it and have the patients to explain it to the uninitiated to keep a running discussion going.
I think Stefan’s is an excellent summary – and would add these caveats and additions:
¢ Shell commands require that a new process be spawned every time and there is a latency associated with doing so.
¢ It is very rarely a good idea to use a do shell script inside a loop if there’s any Vanilla AppleScript way to do the same thing.
¢ Shell scripts provide powerful tools for building folder (directory) hierarchies
¢ Shell commands provide AppleScript access to Spotlight metadata, specifically mdfind & mdls.
¢ Spotlight “knows” a lot more about a file than “info for” does.
¢ The shell provides excellent tools for dealing with plist files (defaults read/write).
¢ The shell provides powerful regex utilization in several of its tools (grep, awk, etc.)
I like Jerome’s comments, summarizes my position nicely. I have no fear or intimidation of shell per se, I’ve been programming on-and-off since personal computers have been around (line-BASIC on a Commodore PET doesn’t get much older for personal computers…), and my email program is MailSmith which made me learn to love GREP. But like Jerome said, time is an issue sometimes. I have a laundry list of things I want to learn: Perl, PHP, UNIX, etc. but no time to learn them. AppleScript kinda lets me ad-hoc projects quickly. I often end-up fine tuning them later, rare any of my scripts stay v1, most get to at least v3 before I’m reasonably happy, and by that time they go from 100% AppleScript to a sensible mix of AS and shell.
I think patience and instruction is the key. No offense, I’ve read MAN pages before, and for the most part I hate them…the folks who write them need to shoot for a more “UNIX for dummies” bar sometimes. But the folks here who have taken the time to walk me ploddingly through some of the shell solutions they’ve provided me have been far more useful than any MAN page or O’Rielly text.
Good to know my own “line” isn’t that much different than anyone elses, my toolbox is just more limited currently so I bias AS a bit more.
I am going to use “do shell” when it shortens scripts. A good example is the date function or the find command. In the shell often it is only one command to be executed whereas in Vanilla AppleScript you have to write a lot of lines and to parse data.
IMHO it is always a difficult decision wether to use AppleScript itselft or the shell. It may depend on speed issues (e.g. in repeat loops) or on special functions.
One fortune I found out is that shell commands does not present Finder windows, e.g. if copying or moving files. This speeds processes up. Otherwise sometimes the “do shell script” command lasts in longer execution by it’s call. So it’s always worth to test, how many ticks the one approach takes or the other, if the application is performance related.
For me, “do shell script” is a very welcome feature, that may be be used sometimes and sometimes I like it, sometimes I hate it. It depends on the special circumstances. So no general statement as such. - As live is.
