Making Finder Folders

Hey all… I’m at a complete loss. I just updated to Mavericks, and I honestly can’t tell what has changed to make this script go wrong.

It USED to name the top level folder the result of the input ex: (1234 - FolderName)

But now, it names every new folder “GO! - GO!”, taking the result of the buttons pressed in the 2 dialog boxes. The internal hierarchy is fine, no issues there…

I keep reading my script, hoping to find something, but it looks all correct to me. Is there something I’m missing?

Thanks, guys!

(* This is the location of the main folder. This folder has to exist somewhere.*)
set theLocation to (((path to home folder) as text) & "Documents:Creative Jobs") as alias




(*This is the initial dialog box that pops up.*)
display dialog "What is your job number?" default answer "0000" buttons {"Cancel", "GO!"} default button 2 with icon alias ((path to me) & "Contents:Resources:My Icon.icns" as string)
copy the result as list to {text_returned, button_pressed}

(*This is the second dialog box that pops up.*)
display dialog "What is the job description?" default answer "Description" buttons {"Cancel", "GO!"} default button 2 with icon alias ((path to me) & "Contents:Resources:My Icon.icns" as string)
copy the result as list to {Job_Description, button_pressed}


try
	tell application "Finder"
		(*This makes the first folder that contains ALL the folders. It uses info from the dialog boxes to name the initial folder.*)
		set JobFolder to make new folder at theLocation with properties {name:text_returned & " - " & Job_Description}
		
		
		(*This is the first subfolder. The key is making a new folder AT the initial folder.*)
		set assetsFolder to make new folder at JobFolder with properties {name:"Assets"}
		
		(*All these are folders within the Assets subfolder.*)
		set FontsFolder to make new folder at assetsFolder with properties {name:"Fonts"}
		set DocFolder to make new folder at assetsFolder with properties {name:"Documents"}
		set imagesFolder to make new folder at assetsFolder with properties {name:"Images"}
		set logoFolder to make new folder at assetsFolder with properties {name:"Logos"}
		
		
		set ProofsFolder to make new folder at JobFolder with properties {name:"PDF Proofs"}
		set ProductionFolder to make new folder at JobFolder with properties {name:"Production Files"}
		
		set WorkingFolder to make new folder at ProductionFolder with properties {name:"Working Files"}
		set FinalFolder to make new folder at ProductionFolder with properties {name:"Final Files"}
		
		
		
		
		
	end tell
on error the error_message number the error_number
	display dialog "Error: " & the error_message buttons {"OK"} default button 1 with icon alias ((path to me) & "Contents:Resources:My Icon.icns" as string)
end try

Hello.

The problem in your script is that you assume the text to be pulled off first, then the button, when you use the result of the dialog.

I can inform you, that in Mavericks, they have reversed the order the two elements gets returned from a display dialog.
In other words, your script worked, as long as the assumption of order held.

It is a much better approach to use something like:

set {theText, theButton} to {text returned, button returned} of (display dialog "Maverick is:" default answer "" buttons {"Wonderful", "Great", "Awesome"} default button 3)

Hi. The text/button returned order is reversed. As you aren’t using the button for anything, it would be better to specify the desired key:

(*This is the initial dialog box that pops up.*)
set text_returned to (display dialog "What is your job number?" default answer "0000" buttons {"Cancel", "GO!"} default button 2)'s text returned

(*This is the second dialog box that pops up.*)
set Job_Description to (display dialog "What is the job description?" default answer "Description" buttons {"Cancel", "GO!"} default button 2)'s text returned

edit: McUser beat me to it.

For years we were said : CAUTION, the returned result is a record, don’t trust upon the order of its components.
Is it surprising that those which didn’t took that in account are now annoyed ?

Yvan KOENIG (VALLAURIS, France) jeudi 21 novembre 2013 18:00:38

Hi,

the value of button returned is not needed as the Cancel button aborts the script anyway.
This is another version using the shell mkdir command to create the folder structure


(* This is the location of the main folder. This folder has to exist somewhere.*)
set theLocation to POSIX path of (path to documents folder) & "Creative Jobs/"
set myIcon to (path to me as text) & "Contents:Resources:My Icon.icns"

(*This is the initial dialog box that pops up.*)
set {text returned:jobNumber} to display dialog "What is your job number?" default answer "0000" buttons {"Cancel", "GO!"} default button 2 with icon alias myIcon

(*This is the second dialog box that pops up.*)
set {text returned:jobDescription} to display dialog "What is the job description?" default answer "Description" buttons {"Cancel", "GO!"} default button 2 with icon alias myIcon

set folderpath to POSIX path of theLocation & jobNumber & " - " & jobDescription
set folderStructure to "/{Assets/{Documents,Fonts,Images,Logos},'PDF Proofs','Production Files'/{'Final Files','Working Files'}}"
do shell script "/bin/mkdir -p " & quoted form of folderpath & folderStructure


set {text returned:jobNumber}

:cool:

StephanK assumption is wrong.

If I run :

set {text returned:jobNumber} to display dialog "What is your job number?" default answer "0000" buttons {"Cancel", "GO!"}

On a system which is not speaking English, clicking the button named [ Cancel ]
returns :

{button returned:“Cancel”, text returned:“0000”}

To exit directly the button must be named according to the localized system.
Here such button must be named [ Annuler ] and it correctly returns :
error “Annulé par l’utilisateur.” number -128

It’s why I use this piece of code :

tell application "Finder" to set cancel_loc to localized string "AL1"

set {text returned:jobNumber} to display dialog "What is your job number?" default answer "0000" buttons {cancel_loc, "GO!"}

Yvan KOENIG (VALLAURIS, France) jeudi 21 novembre 2013 19:44:36

This is unrelated to the subject. I see many on this site and elsewhere using a construct like the one used above:
“/bin/command …”
Could somebody please explain why it is necessary or better practice to add the full path to a standard UNIX command?
They all seem to work well for me without the full path.

Cheers, Chris

normally it’s not necessary to specify the full path because the standard binary paths are included in the $PATH environment variable.

Personally I’m used to specify full paths for other purpose, that’s all

Thanks, Stefan.

Actually, specifying either full path, or setting the path to where you’d normally expect to find the command is a good practice.

Many unix users at least, roll’s their own command and put it in their $HOME/bin, which if they have tinkered their system properly, will show up first, also in a do shell script command, -if they have tinkered it properly.

In this case with the mkdir -p command; would you bet on that every user that had rolled their own version of the mkdir command also had implemented the -p option?

I consider specifying the path to a command that comes installed right there, to be the best practice! :slight_smile:

i guess 95% of the users don’t tinker their systems with custom versions of the standard binaries
And the other 5% know what they’re doing.

Or remember what they have done…

But if you have tinkered one system with great success, then you may tinker the co-workers system as well, and then if a co-worker experience trouble with your solution, then you may actually end up debugging it. :expressionless:

This isn’t a biggie with a shell script of one line, or when you pass something over to someone who understands Applescript and can read the log file. But to one that doesn’t script their machine, the problem may be unsurmountable, and you may have to invest time in solving it. So, specifying a full path to the unix commands, may solve all of that. :slight_smile:

Hi McUsrII,

Look, I can see why generally specifying the full path for a command is easy to do and good practice to avoid potential problems.

This IMHO, is especially true when passing scripts to the “5%” type users, who as you say, may have tinkered with their system and/or could have their own command in addition to the standard one. But again wouldn’t good practice lead those users to name their custom command slightly differently, for their own sanity?

However, when passing scripts to members of the “95%” type users, who haven’t anything but standard commands in standard directories, I can’t really see how one could have problems with them. Unless of cause, the script contains some non-standard/custom command. Then I’d think, one would include an installer for that command, or better, include it in the script or applet bundle, which is what I’ve done once or twice :wink:

Cheers, Chris

Hello.

Well, it doesn’t cost much to specify the full path, in comparision to having to debug something by skype, mail, or something, because you can’t reproduce the error on your machine.

The worst situation, if only situation, which is messy is when the 95% user has a friend among the 5%.

It is no big deal for me, I just know that typing/pasting in the path, may save me some future trouble. :slight_smile:

I love the MacScripting community. Thank you all for your help!

Many internet discussions these days quickly devolve into unpleasantries, it’s nice to see your civility! Cheers to everyone!


try
set thanks_level to infinity
end try

Hi flex20,

From a recent discussion, I learned that there are two different ‘echo’ commands. The builtin ‘echo’ doesn’t allow the -n flag while ‘/bin/echo’ does:

do shell script "echo -n 'hello'" without altering line endings

→ "-n hello
"

do shell script "/bin/echo -n 'hello'" without altering line endings

→ “hello”
I think it was that just ‘echo’ is the builtin bash command.

gl,
kel

Hi kel,
I’m glad I asked the question :wink:
Stefan confirmed that normally the path isn’t really required;
McUsrII made the point that there are many situations where it is safer or even required. In my first sentence in my reply, I actually agreed that it is good practice and easy enough to do;
You point to another circumstance where the path makes all the difference. BTW, I didn’t know that there could be two standard commands with the same name.

My conclusion: it is easy and safer to use the full path :cool:

Thanks to all,
Chris

Also, an apology to the OP for rudely changing his subject. Note to me: not a nice thing to do; open your own post :confused:

I welcome the tangent!

I have the script below, and I’d like to add an “open” command to bring the folder to the front. I’ve tried activating Finder and opening (just below the shellscript,) but it gives a “folder doesn’t exist” error.

Ideas?



(* This is the location of the main folder. This folder HAS to exist. As it is, the folder will have to be in user/whoever_you_are/documents/Creative Jobs*)
set theLocation to POSIX path of (path to home folder) & "Dropbox/Team Folder/0 - Working Files/Dropbox/"
set myIcon to (path to me as text) & "Contents:Resources:My Icon.icns"

(*This is the initial dialog box that pops up.*)
set {text returned:jobNumber} to display dialog "What is your job number?" default answer "0000" buttons {"Cancel", "GO!"} default button 2 with icon alias myIcon

(*This is the second dialog box that pops up.*)
set {text returned:jobDescription} to display dialog "What is the job description?" default answer "Description" buttons {"Cancel", "GO!"} default button 2 with icon alias myIcon

try
	set folderpath to POSIX path of theLocation & jobNumber & " - " & jobDescription
	set folderStructure to "/{'Artwork'/{Final,Proofs},'Assets'}"
	do shell script "/bin/mkdir -p " & quoted form of folderpath & folderStructure

	tell application "Finder"
				open alias theLocation
			end tell
	
on error the error_message number the error_number
	display dialog "Error: " & the error_message buttons {"OK"} default button 1 with icon alias ((path to me) & "Contents:Resources:My Icon.icns" as string)
	
end try