MacOS – How to get automator to act on multiple folders

automatorfoldersmacos

I have a number of folders in the following format:

Folder_Name_1
    Converted_Files
        file1.aiff
        file2.aiff
             :
             :
        fileX.aiff
Folder_Name_2
    Converted_Files
        file1.aiff
        file2.aiff
             :
             :
        fileX.aiff
  :
  :
Folder_Name_nnn
    Converted_Files
        file1.aiff
        file2.aiff
             :
             :
        fileX.aiff

I have written a bash script that will move file1.aiff, file2.aiff, etc. up one level into Folder_Name_n and then delete "Converted_Files".

Automator will only act on one Folder_Name_n at a time.

What I want to do is have automator act on Folder_Name_1, then Folder_Name_2, all the way up to Folder_Name_n.

Here is my automator script:
Automator Flow

Here's the bash script as text:

cd "$1"
cd Converted_Files
mv *.aiff ..
rm .DS_Store
cd ..
rm -r Converted_Files

Thanks.

Best Answer

As you were not too clear on the type of Automator workflow you've created, I'm going to focus primarily on the code you're using in the Run Shell Script action.

The following example Automator workflow was created by File > New > Workflow in Automator with a Get Selected Finder Items action and a Run Shell Script action added to it, with the settings as shown in the image farther below.

Testing was done with a selection containing both files and folders which included both the real targets of the Automator workflow's Run Shell Script action, and others as if accidentally selected if you will. With the following files and folders selected in Finder:

.
├── Archive.zip
├── Folder_Name_1
├── Folder_Name_2
├── Folder_Name_3
├── Foobar
└── Foobar.txt

The following expanded tree view, of the selected files and folders shown above, obviously contains both files which are not the real targets of the workflow as well as a folder not containing the expected contents. This was done to test that the example bash code works as expected.

.
├── Archive.zip
├── Folder_Name_1
│   └── Converted_Files
│       ├── file1.aiff
│       └── file2.aiff
├── Folder_Name_2
│   └── Converted_Files
│       ├── file1.aiff
│       └── file2.aiff
├── Folder_Name_3
│   └── Converted_Files
│       ├── file1.aiff
│       └── file2.aiff
├── Foobar
│   └── Barfoo
│       └── More Foobar.txt
└── Foobar.txt

8 directories, 9 files

After running the workflow from Automator on the selected files and folders in Finder, the following shows the new expanded tree view of the original selection expanded tree view:

.
├── Archive.zip
├── Folder_Name_1
│   ├── file1.aiff
│   └── file2.aiff
├── Folder_Name_2
│   ├── file1.aiff
│   └── file2.aiff
├── Folder_Name_3
│   ├── file1.aiff
│   └── file2.aiff
├── Foobar
│   └── Barfoo
│       └── More Foobar.txt
└── Foobar.txt

5 directories, 9 files

As you can see in the image below, and in conjunction with the information presented above, the Automator workflow completed without error and only processed the appropriate target folders even though additional non-targets were sent to the Run Shell Script action as shown above.

Also note that additional testing was done with the target folders /Folder_Name_N/Converted_Files/ containing non .aiff content to insure that other then the moved .aiff content did not have to be explicitly deleted, e.g. rm .DS_Store was not necessary, as the -r option of the rm command will attempt to remove the file hierarchy rooted in each file argument. You might also consider using the -f option too. (I've already added it to my example bash code, so remove it if you don't want to use that option.)

Automator Workflow Image

Example bash code for the Run Shell Script action:

for d in "$@"; do
    [ -d "$d" ] || continue 
    if [ -d "$d/Converted_Files" ]; then
        cd "$d/Converted_Files" || exit 
        for f in *.aiff; do
            mv "$f" ..
        done
    fi
    cd ..
    rm -rf "Converted_Files"
done

Note that the example bash code is just that, and may not contain all error handling as may be appropriate/needed/wanted. The onus is always upon the user to implement any appropriate/needed/wanted error handling with whatever code one chooses to use.

Testing was preformed under macOS High Sierra 10.13.6.