Re: Finding Filenames that contain a certain string
Re: Finding Filenames that contain a certain string
- Subject: Re: Finding Filenames that contain a certain string
- From: "Stockly, Ed" <email@hidden>
- Date: Fri, 20 Jul 2007 12:19:49 -0700
- Thread-topic: Finding Filenames that contain a certain string
This topic has digressed and if you've already had enough, just skip.
(I'm on digest so I'm responding to a number of posts )
> set fileList to {}
> repeat with asc from (ASCII number "a") to ASCII number "z"
> set fileList to fileList & ("l325010" & (ASCII character asc) as text)
> end repeat
>
> [...continue with Ed's routine]
>
> This is every bit as readable to me as:
>
>> "ls -1 " & strImageRef & "[a-z]*"
I'd say that is much more readable, but this would be even faster and is
more readable:
set filenames to {}
set alphabet to every item of "abcdefghijklmnopqurstuvwxyz"
repeat with thisletter in alphabet
set the end of filenames to thisletter & "325010"
end repeat
tell application "Finder"
choose from list filenames
end tell
(Of course, all this goes way beyond the scope of what the original poster
was asking for)
>
> ...and is traceable and debuggable in Script Editor or Script Debugger.
>
> If there's a performance penalty for building a large list, keep the
> code in comments, run it once, and paste the results directly into the
> script.
Seriously? A penalty performance for building a list of 27 letters?
> I always prefer an AppleScript solution to a shell one unless
> the AppleScript one is just too slow or impractical (I'll pick a shell
> command over a non-Apple scripting addition most times so I don't have
> to worry about installing things), and even if I were to use the "ls"
> command for speed on a huge or remote folder, I'd want the AppleScript
> version handy.
Well put, and I don't really disagree with that, but here's what I've
noticed and what I was responding to.
There are some this list (which is the AppleScript users list) who seem to
respond to any appleScript question with an "anything but appleScript"
solution.
Which is fine for experienced scripters. My concern is that this list is the
best (and possibly the only) interactive support for new applescripters.
That's why it was created in the first place....
>
>
> Ed: That's twice now you've said something about there being too many
shellscript replies on here; I think you are both succumbing to selective
attention and overreacting.
Mark: I'm sure it's more than twice, you may be an order of magnitude off
: )
> There are certainly solutions that are better done with nothing but
AppleScript - heck, I'm probably one of the more "egregious" shellscripters on
here, and I just replied an hour or so ago on the other thread (about renaming
files to remove a level of subdirectory) that Finder scripting was the way to
go. If you're keeping score at home, that's 50% pure AS, 50% "do shell script"
in one day of my contributions.
On person's postings on one day does not adequately describe the situation.
>>> But, I also don't think that "do shell script" should be avoided as if it
were somehow impure. There are occasions where it is appropriate, where the
equivalent Applescript-only solution is more cumbersome or less efficient or
both.
So, in this case the original poster was given an incomplete, fairly obtuse
shell script snippet. I provided a very basic, but fairly complete
appleScript solution that is easy to decipher and would run faster than the
shell script.
But somehow that's more cumbersome or less efficient?
>>>I feel that this is such a case, although obviously the "cumbersome" part is
a subjective opinion. (At least, I think it's obviously subjective; you seem to
be stating as a fact that the AS-only solution is "better". I'm curious about
your definition.)
Better: Faster, easier to understand, easier to debug
> In the particular problem under discussion, I feel (see? subjective) that a
regex-based solution - where you can say "does this string match the pattern
l3105[a-z]" - is cleaner then a loop-based solution where you have to say "does
this string match l3105a? What about l3105b? OK, what about l3105c?" etc. And
there seem to be others on the list who agree.
Sure you can imagine any added complexity to any question and decide that a
non-applescript solution would be appropriate. First, what's the point,
second, even that is fairly simple to resolve in plain vanilla applescript.
>> The use of regexes (or other pattern matching) still doesn't mean you have to
use the shell, of course. Satimage's regex capabilities will do the trick. But
unlike "do shell script", Satimage doesn't ship with the OS (does that make it
less pure/"vanilla" in your eyes?).
People write scripts that to be distributed on macs which may or may not
have additional scripting additions installed.
Also, going back to the original purpose of this list, novice
appleScripters should be given applescript solutions.
Many people, myself included, came to appleScript and scripting because the
language is so easy to read, write and learn.
>>>Is there a users list that uses shell scripting to solve all these problems?
There is a list dedicated to Mac Scripting, which includes shell scripting,
PERL, PYTHON, USERTALK, HyperTalk, etc. etc.
<http://listserv.dartmouth.edu/scripts/wa.exe?A0=MACSCRPT>
This list grew out of that one, in part because novice appleScripters were
flooded with non-applescript solutions when they asked simple applescript
questions.
>>>Since AppleScript implements 'do shell script', anything that it can spawn is
legal chat on this list.
That's true, it is "legal" chat, but it is also "legal" to discuss its
appropriateness. Legal does not equal appropriate.
>>>The discussion of "vanilla Applescript" versus using an osax or other source
is usually pretty silly. Someone will post their "vanilla" Applescript script
and the first thing it contains will be a call to StandardAdditions or to some
application, that's no longer vanilla.
The use of flavoring to describe appleScript goes back about 10 years and
this is how I recall it was resolved:
Pure appleScript: no scripting additions, no application commands
Plain vanilla appleScript: plus the scripting additions and applications
that are installed in the standard install
French vanilla: same as plain vanilla, plus the most commonly installed
scripting additions (in those days that included JonsCommands and something
called Tonaka's OSAX.
Once you get into to using do script or do shell script to call other
languages you've gone beyond vanilla and could be anywhere from chocolate to
frutti-tutti
>> They forget that calling Standard additions for current date is not really
any different than calling it for do shell script.
The difference is that you can master one language (appleScript) and do all
sorts of wonderful things, like getting and manipulating dates.
To effectively use shell scripting you must learn a second scripting
language, which, in terms of human readability, is the opposite of
appleScript.
>>>There are times when shell scripting is the best, shortest, most maintainable
method. It is available on every OS X using Mac as it is supplied by Apple. By
the usual criteria, that makes it vanilla.
No. Not at all. AppleScript is a language and shell scripting is a language
that is not appleScript. "Do script", does not magically turn shell,
python, usertalk, visual basic etc. into appleScript.
>>>I posted this the other week, would this not do the trick?
>>tell application "Finder" to set theFileList to (files of entire contents of
(choose folder) whose name contains theSearchString) as alias list
That was a good snippet Nick, but didn't quite meet the OP's request. The
original issue has long since been resolved, now the discussion has
digressed
>>> Besides, launching other programs is what the shell was designed to do.
>>>It's also what AppleScript is designed to do. I think shell and AS work well
together.
AppleScript was designed to do something very different. It was designed to
allow users access to the data and to offer a high degree of control of any
scriptable application.
>>>Oh, about the remark that every shell command has its own syntax: every
scriptable app has its own dictionary, too. I'm no slouch atAppleScript, but I
still have no clue about scripting apps I don't use, like Filemaker and
InDesign and so on.
But that's appleScript's bread and butter. You use the same basic language
and techniques to control Quark, inDesign, Excel, Entourage, etc. etc.
without having to learn a new scripting language for each application.
That's why we even have an appleScript.
>>>>do shell script "defaults write com.apple.dock mineffect " & (button
returned of (display dialog "Which Dock effect do you want?" buttons {"scale",
"genie", " suck"})) & ";killall Dock"
>>I don't know of any other way to do this without a shell script.
Wouldn't you prefer if Apple made the dock scriptable? Wouldn't we all
prefer if apple made all their apps fully scriptable?
(One thing I don't like about shell scripting is it let's apple off the
hook, rather than making some things scriptable they just give us shell
scripting.)
> The difference is that "do shell script" involves using a scripting language
other than Applescript. In order to use it, you have to know at least one
additional scripting language.
>>> Begs the question as to what is "pure English" though.
>>>These days, a noticeable language trend is
globish<http://en.wikipedia.org/wiki/Globish>. And there is a parallel in
computer languages.
But this is the AppleScript list, set up for AppleScript, not the computer
language list or the general mac scripting list.
This list was created to give appleScript users (particularly new users) a
place to learn applescript without being bombarded with information about
other languages and "any solution but applescript" responses.
That's why this list is here.
ES
_______________________________________________
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