Making Finder Folders

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


theLocation is defined as a POSIX PATH but the Finder is perfectly unable to treat such object.

Try to use :

tell application "Finder"
       open POSIX file theLocation
 end tell

Yvan KOENIG running Sierra 10.12.6 in French (VALLAURIS, France) vendredi 22 septembre 2017 12:01:11

I’ve tried different combinations, but I get errors every way I try it.

When I try

tell application "Finder"
		open folderpath
	end tell

I get: Error: Finder got an error: Handler can’t handle objects of this class.

When I try what you sent, it errors with:

Error: Finder got an error: Can’t get POSIX file “/Users/xxx/Dropbox/Team Folder/0 - Working Files/Dropbox/”.

Oops, I forgot that POSIX file belongs to the OSAX Standard Addition so it can’t be called in the tell application “Finder” block.

Try :

set theFile to POSIX file theLocation
tell application "Finder"
	open theFile
end tell

If it continue to fail add these instructions to check that the file really exists.

tell application "System Events"
	exists disk item theLocation
end tell

It will return true if the item exists, false if it doesn’t exist.

Yvan KOENIG running Sierra 10.12.6 in French (VALLAURIS, France) vendredi 22 septembre 2017 19:07:59

Wonderful. Thank you! It was enough to get me where I needed to go.

The final command that worked was this:

set theFile to POSIX file folderpath
	tell application "Finder"
		activate
		open theFile
	end tell