Get the path of a freshly created folder

Hello all,

what I’d like to do is this:

  1. have the script ask for a folder name
  2. make a folder with the name that was given
  3. make a sub-folder inside that folder, and
  4. save a file in the sub-folder

I’ve got steps 1 through 3, but how can I save a file in that sub-folder that I made? How do I get the path of the sub-folder that was just created? The name of the sub-folder will (by design) always be different, so I can’t set path in stone…I have to use a variable. I just don’t know how to do it.

Here’s the script I’ve got so far.
“set thePath to choose folder with prompt “Choose destination.”” is the sticking point…

thanks in advance :slight_smile:


display dialog "Enter the Print Number and Filename" default answer "A12345P Filename"
set textReturned to the text returned of the result
set thelocation to desktop
tell application "Finder"
	set the_folder to (make folder with properties {name:textReturned})
	try
		set olddelims to AppleScript's text item delimiters -- save their current state
		set AppleScript's text item delimiters to {" "} -- declare new delimiters
		set someText to textReturned
		set folderName to text item 1 of someText
		set fileName to text items 2 through end of someText as text
		make folder in the_folder with properties {name:folderName & " Seps"}
		make folder in the_folder with properties {name:folderName & " Setup Sheets"}
		make folder in the_folder with properties {name:folderName & " Extras"}
		set AppleScript's text item delimiters to olddelims -- restore them
	on error
		set AppleScript's text item delimiters to olddelims -- restore them in case something went wrong
	end try
end tell
set printNum to text item 1 of someText
set finSep to fileName & " " & "DAS" & " " & printNum & "sp.ai"
set finSetup to fileName & " " & "DAS" & " " & printNum & "ss.ai"
tell application "Finder"
	set thePath to choose folder with prompt "Choose destination."
	set newFilename to finSep
	set newFilePath to thePath & newFilename as string
	tell application "Adobe Illustrator"
		activate
		set docref to make new document
		set textRef to make new text frame in docref with properties {position:{200, 200}, contents:"this text"}
		save docref in file newFilePath as Illustrator with options {compatibility:Illustrator 11, preview:color Macintosh, embed linked files:true}
	end tell
end tell

So, you want to use the path to one of the previously created folders (probably the “Seps” folder?) instead of prompting the user to choose one?

The short answer is to use something like set sepPath to result as Unicode text to right after one of the make folder commands to capture the path to the new folder. Then later, append the filename to this saved path string.

I also have some recommendations for some changes to the code. They do not really affect its functionality, but they might be useful nevertheless.

I do not have Illustrator, so I can only test and offer suggestions on the initial part of the script. I am assuming that Illustrator will be able to take the final HFS-style pathname in newFilePath and carry out its save operation the way you have written it.

Overall, the code is solid, but it does exhibit a couple of things that go against some “best practices”.

The first “best practice” is that nested application tell blocks should be avoided. Nesting blocks make it seem like the outer block’s terminology would also be available in the inner block, but this is not the case. If you need to switch back and forth between applications, it is best to use consecutive, independent application tell blocks to make the switching apparent. In this your script, the surrounding Finder tell block is not actually necessary since the choose folder command is not part of FInder (it comes from the StandardAddition OSAX) and the subsequent string manipulation does not require it either.

The next “best practice” is to minimize application tell blocks. Pull it out anything that can be done outside of the block. The text item processing being done in the Finder tell block does not require Finder. In fact, since the string processing depends only on the data from the initial display dialog, all the manipulation can be done before Finder even makes the first folder. Pulling this code out means that the creation of the subfolders will no longer be in a try block. Because the containing folder is brand new (and thus empty), the later make new folder commands are unlikely to fail (and if they do fail, it seems to me that you would want the errors to be fatal (not swallowed by the try block) since the directory structure would be incomplete). A small advantage to moving the text item delimiter operations out of application tell blocks it that you can drop the AppleScript’s prefix (such prefixes are only there to escape from the context implied by the application tell block).

Third, there is a potential error when printNum gets its value. The expression uses text item, but at that point in the program the value of text item delimiter’s has been restored to its original value. This probably works most of the time since the default value for text item delimiters is the same as the value you explicitly use earlier. But if the code was run with text item delimiters set to some other value, printNum would have a different value from folderName, even though they were set with the same expression and the same value for someText. Since it looks like you already have the value you want in folderName, I would just use that variable everywhere (and delete the set printNum to statement). Better yet, since printNum is probably a better name for the variable, use that name everywhere (but still delete the original set printNum to statement that uses an uncontrolled value for text item delimiters).

Last, there are a few cleanups and style changes that you might find useful.

thelocation is unused. Maybe it was intended to be used as make new folder in theLocation . for the initial folder. But to do that you need to move set thelocation to desktop into the Finder tell block because the plain AppleScript desktop is not the same as desktop inside a Finder tell block! This is due to that implied context I mentioned earlier.

The value in someText is always the same as the value in textReturned. There is no need for two variables that always have the same content (from the same source). Pick the better name (or a new one) and stick to that throughout the program.

An indexed text item can be used as an endpoint for text . through . of someStringValue. This lets you avoid the text to list to text conversion of set fileName to text items 2 through end of someText as text by writing it as set fileName to text (text item 2) through end of someText.

" " & “DAS” & " " can just be written as " DAS ", or if you want to emphasize the spaces, space & “DAS” & space.

finSetup is unused. It looks like you intend to use it, but have not gotten there yet.

display dialog "Enter the Print Number and Filename" default answer "A12345P Filename"
set printNumberAndName to the text returned of the result
try
	set olddelims to text item delimiters -- save their current state
	set text item delimiters to {" "} -- declare new delimiters
	set printNum to text item 1 of printNumberAndName
	set fileName to text (text item 2) through end of printNumberAndName
	set text item delimiters to olddelims -- restore them
on error
	set text item delimiters to olddelims -- restore them in case something went wrong
end try

tell application "Finder"
	set thelocation to desktop
	set the_folder to make folder in thelocation with properties {name:printNumberAndName}
	make folder in the_folder with properties {name:printNum & " Seps"}
	set sepPath to result as Unicode text
	make folder in the_folder with properties {name:printNum & " Setup Sheets"}
	set setupPath to result as Unicode text
	make folder in the_folder with properties {name:printNum & " Extras"}
end tell

set finSep to fileName & " DAS " & printNum & "sp.ai"
set finSetup to fileName & " DAS " & printNum & "ss.ai"
set newFilePath to sepPath & finSep

tell application "Adobe Illustrator"
	activate
	set docref to make new document
	set textRef to make new text frame in docref with properties {position:{200, 200}, contents:"this text"}
	save docref in file newFilePath as Illustrator with options {compatibility:Illustrator 11, preview:color Macintosh, embed linked files:true}
end tell

wow. Thanks a ton, that was super-helpful. The set sepPath to result as Unicode text was exactly what I needed…worked like a charm.

yea, the code’s a bit messy in places…I’m still in the “please God make it work” stage :P. I noticed the delimiter problem when I ran the trial this morning, and after I fixed it there were no other issues.

thanks, too, for all the suggestions. As you can tell, I am untrained, and what I’ve cobbled together is just bits and pieces of other scripts. It’s slowly dawning on me how to do things correctly. I figure a lot of what I have could be done with some kind of loop, but I just don’t know how to set it up yet. I’ll figure it out eventually…

anyway, thanks again.
Cheers :smiley:

Hey, guys. Personally, I’d avoid the delimiters, here; a string separated by a space is a word, and it doesn’t warrant further text processing. My method:

tell application "Finder" to tell (make folder with properties {name:(display dialog "name:" default answer "A12345P Filename")'s text returned}) to set {saveLocus, {someNum, fileName}} to {it as alias, (get name)'s words}

Because words will split at and ˜eat’ some types of punctuation, I usually avoid it unless I know exactly what kind of input a script might end up feeding it.

Even if we discount the possibility for useful punctuation like hyphens or periods in the ˜number’ part of the input, the ˜name’ part could very reasonably still contain multiple words. In your one-liner, an input like “A12345P Fergus-Branhold Proposal” would give a fileName of just “Fergus”.

Assuming a single word for the ˜number’ part, your one-liner could use {it as alias, {word 1, text (word 2) through end} of (get name)} instead. But the whole style is much too cramped and convoluted for my taste (not to mention how it forces the dialog to happen in the context of Finder, which may to may not be acceptable”Finder will be inaccessible while the dialog is up because it is application modal).