It can’t be done with brace expansion and, AFAIK, it can’t be done without a loop, but it can be done without a shell script and in a single line. From bash (and thus from do shell script, which invokes bash in MacOS X 10.2 and later) it would look like:
for ((n=1; n<30+1; n++)) ; do mkdir -p $HOME/desktop/testing/chapter${n} ; done
Thus the AppleScript would look like:
do shell script "for ((n=1; n<30+1; n++)) ; do mkdir -p $HOME/desktop/testing/chapter${n} ; done"
Note: Because of the way the for loop operates, the target in the inequality (of the middle parameter) must be greater than the largest value of your range; the +1 thus serves as a reminder of this.
Nice script, Greg! It should be noted that the parent folder should be limited to names which contain no spaces (it failed when I fed it “Greg Test”).
Edit: This appears to overcome the issue:
display dialog "How many subfolders do you want" default answer ""
set x to the text returned of the result
display dialog "What shall the name of the Parent folder be?" default answer ""
set y to the text returned of the result
display dialog "What shall the prefix name of the subfolders be?" default answer ""
set z to the text returned of the result
do shell script "for ((n=1; n<" & x & "+1; n++)) ; do mkdir -p " & "$HOME/desktop/'" & y & "'/'" & z & "'${n} ; done"
An easier solution is to use the quoted form of property of AppleScript strings in the do shell script line; for good form, we should also specifically cast x as a integer:
Thanks again Rainy, the “x as integer” statement prevents someone from entering a non-integer, a nice touch RD. And the ‘quoted form’ solves the issue of folders with a space in the name. This is, by far, the fastest way I’ve seen to create a Parent folder with a bunch of Subfolders. I should have also credited Ernie Rothman, in the original post, for pointing out that this could be done in the first place, so Thanks Ernie.
Actually, a negative value for x isn’t a problem (in so far as the shell command is concerned). It won’t create any directories, but it won’t cause an error in the shell command either. The user will get exactly what they requested: Nothing.
True, but if you run the script asking for -1sub-folders it will simply run without creating the parent or subfolders. Additionally, if the user enters 10.5, it will round it to just 10 subfolders, using 10.6 rounds it 11subfolders.
So as a stop gap, until I add some more error checking, I added as integer to the variable…
It’s just one of those things that I like a distributed script to handle gracefully. It cuts down on complaints from the clueless and it’s one less thing that can be reported as a flaw by those individuals who take great joy in trying to break stuff (I think they hang out in the Feedback section on VersionTracker). 8)
I agree that code should be as robust as possible.
It seems, however, that i over estimated the value of x as interger. In looking at the Applescript Language Guide, i see that there is actually no coercion from real to integer, which explains why the following code:
try
set x to 2.6
return x as integer
on error the errorMessage number the errorNumber
return "Error: " & errorNumber & ". " & errorMessage
end try
I was having some issues with that also, FYI error number -1700 is…
(-1700) bad parameter data or unable to coerce the data supplied [errAECoercionFail]
if you try, as Rob pointed out
get class of 3
-->integer
but if you try...
get class of 3
display dialog result
-->tell current application
display dialog integer
{button returned:"OK"}
end tell
the dialog window says "long"
get class of 3.6
--> real
get class of 3.6
display dialog result
-->tell current application
display dialog real
{button returned:"OK"}
end tell
the dialog window shows "doub"
And: display dialog number
displays “nmbr”. My guess is that these are AppleScript’s internal tokens for these keywords. Remember that AppleScript is multilingual and that in German, for example, the words “integer,” “real” and “number” would all be different; i’ll bet dollars to doughnuts that these four-character tokens don’t change, however. And the tokens do make sense: “long” is generally an integer (in languages like C) whereas “doub” is generally a floating point number.
FYI, i’ve noticed that display dialog accurately displays the quotes and backslashes of the string you’re about to pass to a do shell script command. Since AppleScript sometimes requires extra quotes or backslashes in its source, things can get confusing. Using display dialog (during debugging) is useful to confirm your command is what you really want it to be (as opposed to viewing the command in the results window).