You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Automator quit all

I want a script to close all open applications and empty trash.


Applications and Finder behave differently.

Automator 'Utilities' options appear the best bet, so I am focused there.

I am able to quit all applications, but Finder is stubborn

I can close Finder components as a group inside Automator, but combining that group with 'Quit all Applications' The Automator group of scripts fails to close Finder components (Finder window, Get info, and Inspector).

Here's what I have so far.


Group 1: on it's own closes everything but Finder stuff.

Utilities > Quit all applications

Quit all applications

Group 2: this group works well.

Utilities > Run AppleScript

on run {input, parameters}

tell application "Finder"

empty the trash

end tell

delay 1

return input

end run

Group 3: run on its own this works, but not with 'Quit All Applications'.

Utilities > Run AppleScript

on run {input, parameters}

tell application "Finder"

activate

quit

delay 3

tell application "Finder"

activate

end tell

end tell

return input

end run

Group 4: this one works on its own for Finder stuff, but doesn't work with other groups.

Utilities > Run Shell Script

cat

osascript -e 'tell application "Finder" to quit'

Mac Pro, OS X El Capitan (10.11.6), MacBook Pro - iPhone6+ - Power PC

Posted on Oct 7, 2016 6:04 AM

Reply
22 replies

Oct 7, 2016 6:32 AM in response to Osiyo

I noticed that sometimes AppleScript works, and a second later it stops working.


For now I found a way to make this work. Automator works great asking Finder to empty Trash. So I dropped Trash from group 2 down to group 4, bottom of the Automator collection. Now it works... for now...


Group 1: Utilities > Quit all applications

Quit all applications


Group 2: Utilities > Run AppleScript

on run {input, parameters}

tell application "Finder"

activate

quit

delay 3

tell application "Finder"

activate

end tell

end tell

return input

end run


Group 3: Utilities > Run Shell Script

cat

osascript -e 'tell application "Finder" to quit'

Group 4: Utilities > Run AppleScript

on run {input, parameters}

tell application "Finder"

empty the trash

end tell

delay 1

return input

end run

If anyone knows why this group order works, an explanation would be appreciated.

Oct 23, 2016 7:24 PM in response to Osiyo

What is the purpose of the groups? How are they interrelated in your workflow?


Why are you telling Finder to Quit, then restarting it?


What are you "cat"ing? cat without an argument seems to hang the shell waiting for an argument, so the osascript may never be executed; the string is just cat'd (i.e. printed out).


Also, since you are not using the parameters of the Applescripts, you don't need them in the scripts and you don't need to return them to the next Action.

Nov 20, 2016 1:56 PM in response to Osiyo

This is correction for Sierra: remove GROUP 4 and edit GROUP 2, as shown below.
Drag and drop groups to re-arrange order. Hope this helps.


GROUP 1: Utilities > Quit all applications

Quit all applications


GROUP 2: Utilities > Run AppleScript... replace (* Your script goes here *) with...

tell application "Finder"

activate

quit

delay 3

tell application "Finder"

activate

end tell

end tell

tell application "Finder"

activate

end tell

return input

end run

After pasting or typing above command lines, click AppleScript 'Hammer' icon.


Group 3: Utilities > Run AppleScript... replace (* Your script goes here *) with...

tell application "Finder"

empty the trash

end tell

return input

After pasting or typing above command lines, click AppleScript 'Hammer' icon.

Nov 20, 2016 2:23 PM in response to Barney-15E

The groups are for you to know that it's time to insert another module into the Automator 'application'. Would you prefer 'application module group of text strings'?


Telling Finder to "quit" will close Finder Windows. However, Apple OS needs Finder open to facilitate menubar, run system utilities, etc. Thus, after quiting Finder, we must restart whatever the "quit" has quit! Like this...


tell application "Finder"

activate

end tell


'Cat' was my desperate last-ditch effort to stop Finder's "quit" hanging my desktop. It actually stopped the hang... I have absolutely no idea why.


Parameters? What does Barney mean by parameters? My 2016 Nov 20 correction should be an easier read, perhaps? The GROUP 2 redo issues from decades of writing under-the-shell batch files for machine configuration: when you tell a machine quit something, then typically you must tell it to restart using the same restart text string twice - the 1st to tell it to check its quit, the 2nd to physically restart that something quit. This is because machines are only 1 bit at a time, and that is how machines work.

Nov 20, 2016 2:57 PM in response to Barney-15E

Re parameters (further):


Once Hammer knocks script into shape, then we can see that in addition to "check" behaviour, machine command interpolation allows 'interpretive' layers. AppleScript sets out visual interpretation of those layers brilliantly! The 1st and 2nd 'end tell' leave the poor Finder wondering, "What next?" Tell the boy what to do. That's all.

Nov 20, 2016 4:23 PM in response to Osiyo

Osiyo wrote:


The groups are for you to know that it's time to insert another module into the Automator 'application'. Would you prefer 'application module group of text strings'?

How about "drag in a new Run AppleScript Action?"

Telling Finder to "quit" will close Finder Windows.

How about you just tell Finder to "close windows"

'Cat' was my desperate last-ditch effort to stop Finder's "quit" hanging my desktop. It actually stopped the hang... I have absolutely no idea why.

Likely will not be needed when you no longer need to Quit the Finder.

Parameters? What does Barney mean by parameters?

Each Action in a workflow passes the output from its action to the next action (and all subsequent actions) unless you tell an Action to ignore the input.

In an AppleScript Action, the "input" argument is what is passed from the previous action. Since you don't make use of it in any action, there is no point in returning it at the end of the script.


There is no reason to leave Finder wondering what to do.


You can replace the second and third Run AppleScript Action with

tell application "Finder"

close windows

empty the trash

end tell

Nov 26, 2016 4:45 AM in response to Barney-15E

I kinda like errors, though. Then you know if the thing works, or not. Be brave, Barney. Be brave! ✅


But you could have something there.

So I will 'try' adding your try to a closing argument for the script.

Then we have an 'error' capable frisst run followed bt a bash through anyway, which should leave any error popups but close without hanging.


Others advise that the script hangs.

Nov 26, 2016 5:05 AM in response to Osiyo

The Workflow hangs because the AppleScript command to empty the Trash requires that you click OK on a dialog when the Trash is already empty. The workflow cannot interact with the GUI to click the button (it doesn't even show the dialog to the user), so it hangs waiting for a response.


I don't see anywhere in AppleScript where you can tell it to empty the trash and not display that error messages, so trapping it is the only option I can find.


You could trap for the error and handle as appropriate, but the error generated when the trash has no items is a general error and you might get that same error for some other reason.


tell application "Finder"

close windows

try

empty the trash

on error errMsg number errNum

if errNum ≠ -128 then

display dialog errMsg & ": " & errNum

end if

end try

end tell

Or, better yet, don't cause an error condition to occur:

tell application "Finder"

close windows

set trashCount to count of items in the trash

if trashCount > 0 then

try

empty the trash

on error errMsg number errNum

display dialog errMsg & ":" & errNum

end try

end if

end tell

Nov 26, 2016 7:42 AM in response to Barney-15E

Quorum: Barney’s intervention is perhaps excessive and certainly raises many questions, where there is no popup confirmation.

Finder Preferences › Advanced › Show warning before emptying the Trash (unchecked).


That said, the 'try' operator was efficient at speeding up my QUIT! app, and at the same time altering whatever was causing my system to hang pending reboot, if the Trash was empty. The solution was to add simple ’try' segments prior to simple 'tell' segments.


Reasonable query: copied Quit to Desktop instance. Finder preferences, ‘Show warning…’ checked.

Result with Trash empty: no popup, QUIT! run complete.

Result with Trash content: no popup, QUIT! run complete. No popup, so question must be, what error condition?


So, I don’t exactly know what this means, except that I have an AppleScript run, ignoring User preferences. Why does Barney experience ‘error’ conditions? Any thoughts?

Nov 26, 2016 7:40 AM in response to Osiyo

Automator › Utilities... "QUIT!" application, version 2016-Nov-26.

App-build on 2016 Mac Pro 6 core, home business desktop, basic fiber-optic to residential node to co-axial cable Internet 150mbps.


...Run AppleScript

on run {input, parameters}

tell application "Finder"

activate

try

quit

end try

quit

delay 3

tell application "Finder"

try

activate

end try

activate

end tell

end tell

delay 1

tell application "Finder"

try

activate

end try

activate

end tell

return input

end run


Quit All Applications

Ask to save changes


Run AppleScript

on run {input, parameters}

tell application "Finder"

try

empty the trash

end try

empty the trash

end tell

delay 1

return input

end run

Nov 26, 2016 8:15 AM in response to Osiyo

Run this in Script Editor (not Automator) with nothing in the trash:

tell application "Finder"

empty the trash

end tell


You will see this:

User uploaded file

That error is being generated and processed by Automator. That is what causes the hang you see.

It has nothing to do with the settings in the Finder to warn before emptying.


Again, I'm not sure why you do everything twice, once in a try block and once outside. That makes no sense at all.

And, you are returning "input" for no reason.

The delays are superfluous also.

Automator quit all

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.