Again, this thread seems interminable. If it's putting you to sleep, please
skip it.
Yet you keep refusing to terminate it.
>>> I'm going to call BS on that, again. It's just not so. Some of us reply
with suggestions that the OP use a "do shell script" solution, but I sure
haven't seen that many replies that say "use a different language".
awk/bash/clisp/cut/grep/guile/perl/python/ruby/sed/tcl are not AppleScript
Lauguage. They are either other languages or shells (and shells, IMHO,
constitute almost a different language and syntax for each command). They
are accessible through the AppleScript technology.
My point is that issuing a single shell
command does not constitute "shell scripting". Issuing a shell command is how you do things in the CLI world that lives underneath the shiny exterior of OS X. The fact that you *can* do programmish things that way doesn't make every command you execute a program.
A reply that says use any of these is, in essence saying "use a different
language"
Yes, but IN ADDITION to AppleScript. WITHIN AppleScript. NOT INSTEAD OF AppleScript. That is a fundamental distinction. You seem to be accusing us of trying to foist Applescriptless solutions off on Applescripters, and it just ain't so.
> OK, I'm hoping you'll repeat your rants about the AppleScript language
> there.
Just for the record, the first snippet you quoted was from me. That one you quoted above that last statement was from someone else, perhaps has, but since you didn't bother to attribute it, I don't know for sure. At any rate, to the best of my knowledge I have never issued any "rants" about the Applescript language.
I prefer writing half a dozen lines of AppleScript to writing a single line
of shell scripting.
Ah! And now we come to the crux of the matter. You have a prejudice against shellscripting. That's totally fine, but you have no reason to impose that prejudice on everyone on the list.
Which brings us right back to the beginning of this thread. Mark was in
essence saying that writing a few lines of fairly simple AppleScript was
such a burden, that looping through a list of 26 items was so clunky, that
Shell scripting was required.
I didn't say "required". I never said it couldn't be done with Applescript, just that I feel the shell solution to be both simpler and more elegant. I mean, one line of code is simpler than ten. I suppose elegance is in the eye of the beholder.
As it happens, I do also prefer not to switch languages mid-program. The two preferences were in conflict in this case, and simplicity won.
Let's simplify the requirements a bit and see if that's still the case. What if I wanted to find, from AppleScript, all the C source code files in a folder (instead of filenames matching a more complex pattern as in the OP)? Hm:
set sourceFolder to (choose folder)
tell application "Finder" to set fileList to (every file of sourceFolder whose name ends with ".c") as alias list
That's pretty simple. Not necessarily obvious due to that "alias list" thing, but certainly that's familiar ground to anyone who's spent more than a line of code in a Finder tell block. It's quite legible and relatively easy to come up with.
Now let's take a look at the equivalent using "do shell script":
set sourceFolder to quoted form of POSIX path of (choose folder)
set fileList to paragraphs of (do shell script "cd " & sourceFolder & "; ls *.c")
Well, clearly that is an evil abomination of a program the merest utterance of which will bring the sky crashing down upon our heads. :)
Seriously, that's still pretty simple, in my book. But it's not simpler than the AS; I'd certainly stick with the first solution in this case. But not out of any desire for "purity".
If AppleScript were so grossly deficient as you suggest there wouldn't be
that many people using it to begin with. Unless we're all doing things wrong
and just don't know any better.
Again, you have failed to distinguish your targets, so let me remind the audience that I'm not the one who claimed AppleScript was grossly deficient. Nevertheless, it can be the best way to script Mac applications and still be grossly deficient. The two attributes are not mutually incompatible. "The best" (of a limited set of choices) is not the same as "the ideal".
Mark J. Reed <