CODEWITHSUNDEEP
applescript
SamH
SamH

Reputation: 11

Deleting folders with Applescript doesn't work on some systems

I'm using Applescript to handle part of the work of installers for my products. I've been using the same script for years without trouble, but have had reports from a couple of users recently where the script doesn't clean up after itself, which results in issues. I'm unable to recreate this on my systems and so am wondering if any of you could possibly shed some light on why this is occurring on some systems.

The installers are *.pkg files. The installers create a folder named Contents in the user's home directory with a payload (one or more folders containing *.pyc and *.txt files) along with the Applescript and then calls a shell script that looks like so:

#!/bin/sh

open "$2/Contents/Live AutoConfig.app"

exit 0

AutoConfig.app is the compiled Applescript. It transfers the payload in Contents into the contents of one of more *.app files within Applications. This part works fine. At the end of this transfer, the script should delete the Contents folder. This is what is not working. The code for the clean up looks like this:

on clean_up()
    set temp_path to path to me
    tell application "Finder"
        set script_path to (container of temp_path) as Unicode text
        delete (script_path)
    end tell
end clean_up

When this doesn't work, there are no error messages or anything. The Contents folder simply isn't deleted as it should be. And, yes, I'm sure that clean_up is being called. I find this quite odd since, from a security standpoint, I would think that transferring files into *.apps is more risky than deleting a folder from the Home directory and yet the transfer works fine. Weird.

Some additional info: The installers and scripts were created using 10.5.8 (FWIW, this doesn't appear to be the issue though since the installers still work fine on my other systems running 10.12.6 and later). The users having this issue are running the installers on 10.12.6 and 10.13.6.

Any ideas on why this might be happening?

Upvotes: 1

Views: 179

Answers (1)

wch1zpink
wch1zpink

Reputation: 3142

This is not a direct solution to your problem. A good start to isolating the problem would be to wrap your code inside of a "try" and "on error" statement. This way when your code encounters an error, you can just have that error handler display an alert or actually create a script error log file with some information as to what caused the error. Having your AppleScript create a script error log file would be my personal preference, especially since it is run on several different machines with different versions of macOS. It is entirely possible that the reason the code fails on one computer is different than the reason it fails on another. One could wind up chasing their tail for hours, only to find out the fix works only on one computer but not others etc.

I have a basic try/error routine which will create a script error log file to the user's desktop. Just place the AppleScript code from your AutoConfig.app inside the "try" routine and recompile and save (make sure to keep a copy of your original AutoConfig.app) and redistribute to the computers that trigger the errors. With any luck, their errors will be logged to their desktop when they try running the package installers again

try

    -- INSERT YOUR CODE HERE

on error the error_message number the error_number
    set the error_text to "Error: " & the error_number & ". " & the error_message
        my write_error_log(the error_text)
end try

on write_error_log(this_error)
    set the error_log to ((path to desktop) as text) & "Script Error Log.txt"
    try
        open for access file the error_log with write permission
        write (this_error & return) to file the error_log starting at eof
        close access file the error_log
    on error
        try
            close access file the error_log
        end try
    end try
end write_error_log

You may also want to add a couple “if… then” clauses to address the computers that already have “Contents” folder because those folders were not deleted from the previous install. If that folder is still there it will probably cause an error when your debugging version of the code is run. So you may want to consider adding this following code to the beginning of your script to address that possible issue

set contentsFolder to (path to home folder as text) & "Contents"
tell application "Finder"
    if folder contentsFolder exists then delete folder contentsFolder
end tell

Upvotes: 1

Related Questions