Re: Get every file of the entire contents of a folder. Quickly.
Re: Get every file of the entire contents of a folder. Quickly.
- Subject: Re: Get every file of the entire contents of a folder. Quickly.
- From: kai <email@hidden>
- Date: Wed, 15 Oct 2003 00:53:06 +0100
on Tue, 14 Oct 2003 10:36:14 -0400, Paul Skinner wrote:
>
On Tuesday, October 14, 2003, at 02:44 AM, kai wrote:
>
>
> Come to think of it - I could have cleaned that up a bit better:
>
>
snip compressed, revised, script.
>
>
kai, you're like an AppleScript coffee press.
>
I bet your parent's named you Kaisarandamajewaski and you immediately
>
shortened it to kai. : )
>
Thanks for your input!
I was having a little trouble with "gah-gah" at the time...
>
On Tuesday, October 14, 2003, at 01:57 AM, kai wrote:
>
> Id guess that most of the scripts time is spent finding files, so
>
> any speed enhancements from AS fine-tuning would probably be minor.
>
>
Remarkably, the shell is so fast (unless you traverse directories that
>
you don't have permissions for) that earlier versions spent more time
>
in the TIDs conversions!
Right. In that case, any tweaks should help. :-)
>
> If you wanted flexibility about the order in which parameters appear
>
> in the calling statement, then you could
>
>
snip
>
>
> set folderAlias to item 1 of p's aliases
>
> set searchterm to item 1 of p's strings
>
>
COOL! Why haven't I thought to try that before? I don't care to add
>
positional flexibility, but what a great method.
And thanks to Chris Nebel for pointing out the preferable form for this type
of situation:
set folderAlias to p's first alias
set searchterm to p's first string
(Over 30% faster here.)
>
> Rather disgracefully, I haven't yet had a chance to test/compare
>
> either version - so I hope I've not introduced any typos/errors. (It
>
> looks to me as if you might, by using 'paragraphs 2 thru -2 of
>
> filelist', have been losing the last file found by the shell script -
>
> but I might be wrong about that.)
>
>
I WAS throwing away the last found file. Occasionally the last item is just
>
the disk name, I haven't fully groked this problem yet.
I might just leave you to grapple with that one. ;-)
>
I prefer your method for assigning the variable parameters, although I did add
>
back the 'as text) as alias' coercion. this lets the user pass a string,
>
alias, or folder spec.
Yeah - certainly more flexible in that respect.
>
I had a bit of trouble with the 'rest of' statement and stack overflows, so I
>
reverted to the '2 thru -1' construction.
Hmm... interesting.
My original reason for using 'rest of' was that, OMM, it's slightly (about
6-8%) faster than '2 thru -1'.
The limit for the stack seems to vary depending on what else is going on in
a script - presumably because of what else might already be in the stack.
However, all my tests have indicated that both methods should be very close
in terms of how many listed items can be created before a stack overflow
exception occurs. In each case, the '2 thru -1' construction allowed just 1
more item than 'rest of'.
To give you a couple of examples, I ran a relatively simple script, first
using '2 thru -1' - and then inserting 'rest of'. With '2 thru -1', the
script created lists of up to 4,072 items without error - but caused the
stack to overflow as soon as a 4,073-item list was attempted. On the other
hand, 'rest of' coped with a 4,071-item list, but choked as soon as the
count rose to 4,072.
I then created a more complex script - though still containing the same core
test routine as that used above. The '2 thru -1' method resulted in a stack
overflow when attempting to create a 4,055 list - while 'rest of' fell over
at 4,054 items.
Given the marginal differences between these results, I'm at a loss as to
why your experience should suggest something more significant. Must be
something else going on somewhere...
>
Unfortunately, there was a major bug in the code I wrote. Grep was not the way
>
to go for the containing search. I was getting hits where the file path
>
contained the search term. The 'find' shell command has it's own switch for
>
this. And the results are not only more accurate, but they come back quicker!
problem = opportunity ;-)
>
EveryFileOfFolder({choose folder, ".jpg"})
>
>
on EveryFileOfFolder(parameters)
>
set termExists to parameters's class is list
>
if termExists then
>
set folderReference to (parameters's item 1 as text) as alias
>
set searchterm to parameters's item 2
>
else
>
set folderReference to (parameters as text) as alias
>
end if
>
>
set folderPath to quoted form of (POSIX path of folderReference)
>
set shellFind to "find " & folderPath & " ! -name '\\.*' -type f | tr
>
-s '//' | tr '/' ':'"
>
if termExists then set shellFind to "find " & folderPath & " ! -name
>
'\\.*' -name '*" & searchterm & "*' -type f | tr -s '//' | tr '/' ':'"
Given how the above couple of lines have changed, I'd now be tempted to
restructure them slightly - so that, whichever string value is required,
it's assigned to the variable 'shellFind' only once:
------------------
if termExists then
set shellFind to "find " & folderPath & " ! -name '\\.*' -name '*" &
searchterm & "*' -type f | tr -s '//' | tr '/' ':'"
else
set shellFind to "find " & folderPath & " ! -name '\\.*' -type f | tr -s
'//' | tr '/' ':'"
end if
------------------
(Not quite as concise, but faster when termExists - and no slower if not.)
>
try
>
set filelist to paragraphs of (do shell script shellFind)
>
on error
>
return {}
>
end try
>
>
set prevDelim to text item delimiters
>
set text item delimiters to ":"
>
set DiskName to return & text item 1 of (folderReference as Unicode
>
text)
>
set text item delimiters to DiskName
>
set filelist to (DiskName & (filelist as text) as Unicode text)
>
set AppleScript's text item delimiters to return
(BTW, I removed the above line in my suggestion because I couldn't see that
it was doing anything useful. Perhaps you were originally going to use 'text
items' instead of 'paragraphs'?)
>
set filelist to paragraphs 2 thru -1 of filelist
>
set text item delimiters to prevDelim
>
return filelist
>
end EveryFileOfFolder
===================================================
on Tue, 14 Oct 2003 16:45:01 -0400, you also wrote:
>
On Tuesday, October 14, 2003, at 11:07 AM, Paul Berkowitz wrote:
>
> And why this lower down:
>
> set filelist to (DiskName & (filelist as text) as Unicode text)
>
> Why not just:
>
>
>
> set filelist to (DiskName & filelist) as Unicode text)
>
>
>
> Why lose the Unicode in the paths before coercing it back? You'll lose
>
> all the non-ASCII characters that way and will get errors if there are
>
> any.
>
>
>
> Since I already mentioned this (you didn't replay that time), and
>
> you're still doing it, you must have a good reason I'm missing - maybe
>
> some situation I haven't considered. Please tell. The method itself
>
> looks terrific.
>
>
Unfortunately no. Your assessment is right on. It should be 'set filelist to
>
(DiskName & filelist) as Unicode text)', but I question if that is even
>
necessary since DiskName is already unicode. Doesn't the first item determine
>
type of subsequent appended strings?
------------------------
set foo to "foo" as Unicode text
set bar to "bar"
set foobar to foo & bar
{foobar, foobar's class}
--> {"foobar", Unicode text}
------------------------
Interesting discussion all round.
---
kai
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.