Does 'do shell script' need to be in a tell application "Finder" block

I have a basic question…

Does the “do shell script” need to be in a tell application “XYZ” block ?

I find it difficult to know exactly what functionalities are part of the Finder or another application or directly part of AppleScript.

Is there an easy way to know when to use a tell block ?

Thanks.

Andrew

A good source of information is available under the name “dictionary”.
Look at the Finder’s one to see which are Finder’s commands.
Look at Standard Additions one to see which are belonging to this OSAX.

do shell script belongs to the Standard Additions OSAX so it’s not supposed to be encapsulated in a tell application (Finder or other) one.

Yvan KOENIG (VALLAURIS, France) lundi 2 février 2015 16:35:44

Hello Andrew,

First of all you need to know where the command is defined and stored. This can be done using the dictionary browser of the script editor. when looking up do shell script in the Finder dictionary you won’t find anything. When we look in the dictionary of StandardAddition.osax we’ll find a command named do shell script. So we know that the do shell script command is defined in the StandardAddition.osax.

Still it doesn’t mean anything because some commands can be loaded into another process and executed from there, like user interactions. But almost in all cases, when the scripting addition command doesn’t require a remote process you execute the command in the current application context.

executing a do shell script while in the Finder context can easily be done like this:

tell application "Finder"
	tell current application to do shell script "true"
end tell

when you don’t add the tell current application you can see the difference in the event log. A do shell script may only be executed by the current application and is defined in the info.plist (Context key) of the scripting addition. When the event (command) will be send to a remote application the event will bounce back. AppleScript will notice the bounce back and will try the same event again in the current application context before returning an error. This security is added to avoid running shell commands by other application to obtain elevated privileges.