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
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.
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!
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.
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.
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
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.
Hi kel,
I’m glad I asked the question
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
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
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