2nd option for unzipping

[RunDontStop]

We receive loose PDF files for most customer art, but zip files are a very close second. Lately I am seeing Switch having problems with zip files. When I use the default Unarchive app in Switch I get 3 results:

1. Zip file is successfully unzipped
2. Zip file fails to unzip and goes to Problem Jobs
3. Unzipped result is incomplete

Of course the problem areas are 2 and 3 above. I have noticed that when either of these happen, I am able to successfully unzip the files outside of Switch. Typically I use Archive Utility which is a default app in Mac OS. Because this seems to work, I want Switch to use this app in the event I experience either 2 or 3 above. I have several different ideas on ways to have Switch do this, but does anyone have a good suggestion on a failsafe way to redirect these difficult zips to Archive Utility, so that the unzipped result can continue on in the flow?

When manually unzipping using Archive Utility outside of Switch, the unzipped result and the zip file are always in the same location. That is what concerns me. My understanding is Switch needs the unzipped output, but it needs to be associated with the original zipped input. So a single zip goes into an input folder, then whatever the result is (file or folder) ends up in the output. I need to somehow avoid having both in the output folder, so Switch sees the unzipped as output, easily associated as the same job as the original zip. I am afraid of getting a mixup - an output for one job being associated with the input for a different job. Bear in mind I could have a dozen zips going into a flow, making a mixup a real possibility.

Thanks in advance for any suggestions.

[JimmyHartington]

With the latest version of the Unarchive app I have reported a bug, because it did not unzip my files correctly.
You could try to install the older version and see if it unzips the files correctly.

[RunDontStop]

I recently rolled back to version 5 but I still have problems using Unarchive. I wanted something as a backup, just for when the Unarchive doesn't work out. I completely understand if a switch app might not work sometimes.

I have a crude flow but I am confident there is a much better way to do the same thing. My zips in the flow feed into an Input folder, just before Generic Application. There is a constraint of 1 job in this folder. This folder is in fact a Mac OS hot folder.

When the zip hits a folder the Mac OS launches an app that runs a shell script. The shell script does the following:

1. Makes a brand new directory with a specific fixed name in a specific fixed location.
2. Copies the zip to this brand new directory.
3. Opens the zip in the new location with Archive Utility
4. Copies the original zip in the input folder (the same as copied in #2) to the Switch Generic Application output folder.

So by the time Switch detects the output (which is the original zip) in its output folder, the unzip work has been done by the Mac OS using Archive Utility.

From the output folder in Switch, the original zip continues. Using Wait for Asset it injects the folder created in #2 above, then deletes it. This folder has both the original zip and the zip result.

After Wait for Asset, I use Dismantler to break the zip away from the zip result. I separate the zip and recycle it.

Meantime I have Generic Application set to Perform cleanup so that the next zip is free to enter the input folder with the 1 job constraint (the Mac hot folder).

By this time the folder created in #2 above is gone, deleted by Wait for Asset. The new zip file hitting the Mac OS hot folder will create this folder again, and the whole process repeats itself as jobs flow through.

In my testing this seems to work – if I put a hold before the Recycle for the zip, I can see an equal number of unzipped and zipped results, maintaining a one to one correspondence. But I also realize in the real world, this flow could be thrown off somehow, and the wrong zip result could be applied to a job, especially if a lot of jobs are churning in the flow.

[JimmyHartington]

If you have the folder constraint set to one file, then I do not think you will get a mix up.
Some of my flows utilize this method of a folder constraint set to one file. And then the other files just wait for their turn.
It can be 5 or 100 files.

[freddyp]

...
When the zip hits a folder the Mac OS launches an app that runs a shell script. The shell script does the following:
...

I would think that with some slight modifications you can run the shell script with "Execute command". Are you willing to share the shell script?

[RunDontStop]

Thank you and I thought Execute Command was a possible and faster solution. I confess I do not understand the app. But I am revisiting it now and trying to learn. Here is the script. Right now I am running this script using an Automator app that is triggered by an Automator folder action which seems very inefficient. You can see in the script it's just copying the file and opening with Archive Utility, but maybe it would be better to use the "unzip" command instead of using an app. The Finder close window command is just to clear it out of the way, because Archive Utility always brings up the finder window.

cd /Users/switchuser/Documents/HOTFOLDERS/Second-folder
mkdir MYJOB
cp /Users/switchuser/Documents/HOTFOLDERS/UNZIP-START/*.zip /Users/switchuser/Documents/HOTFOLDERS/Second-folder/MYJOB
sleep 1
open /Users/switchuser/Documents/HOTFOLDERS/Second-folder/MYJOB/*.zip -a Archive\ Utility.app
sleep 1
osascript -e 'tell application "Finder" to close windows'
sleep 1
cp /Users/switchuser/Documents/HOTFOLDERS/UNZIP-START/*.zip /Users/switchuser/Documents/HOTFOLDERS/UNZIP-FINISH

[RunDontStop]

I wanted to give an update on this. I tried creating a shell script file (.sh) but I kept getting nonzero exit code errors. Then I stumbled upon something pretty simple. The command I tried using in the shell script is ditto. I found out the actual ditto app is here:

/usr/bin

So in Execute Command the path is

/usr/bin/ditto

in the arguments I have:

-xk "%1" "%3"

The zip processes in Execute Command and I end up with a folder "ExecuteCommandTemp" with the unzipped result inside. This is easily dismantled.

Please understand – I know next to nothing about shell scripts and command lines but this seems to work. I really want to learn more about this app. It seems extremely powerful. I have always wanted to use it and fumbled around getting nothing but errors, and this is the first time I have actually produced something with it.

I have many flows that use Mac hot folders (such as print hot folders) and these could probably be remade using Execute Command, because in the hot folders all I do is run an app that contains a script.

[freddyp]

Good job! "Execute command" is indeed quite powerful. Go to "All courses" in the Learn section on our website and search for "execute command". You will find a recording of a workshop session from August 2022 that talks about this element in somewhat more detail.

Side remark: there is also the "Apple Automator" app that allows you to run tasks.

[RunDontStop]

Thank you Freddy. I did run across a problem using the ditto command - apparently there are certain zip files that "confound" this command (that's the best way I can explain it). It probably works well for most zips but not all. I came across one zip and used the ditto outside of Switch using Mac Terminal. The contents of the zip is somewhat confusing - it's really just one file, a Photoshop file. When I unzip using the normal Archive Utility I end up with a folder with the Photoshop file inside it. The ditto command does not produce a parent folder - it produces the Photoshop file, and then an empty folder __MAC OS. I figure when it goes through my flow, these loose items probably confuse Switch, and the job goes out as an error – I just get the original zip.

For this reason I tried to revisit the .sh solution. Here I could do more than just ditto, I could make a directory, get the contents to go in it, chain several commands together. Bottom line I simply cannot get the .sh file to work. I went to the eLearning course and looked at the exercise of changing the contents of a text file. I replicated this in Terminal and it works great. I make the .sh (with $!/bin/bash), run chmod on it to give it permissions. When I try to use it in Switch I always get the 255 error. But I will investigate all of this in more detail and see where I get it wrong. The workshop from 2022 probably has good advice.

[freddyp]

Check the debug messages. There you will see the actual command that is executed. That will usually give you an indication of what went wrong. If I were to make a bet: you did not place $1 in the shell script between double quotes.

On Mac there is also an unzip command (it is in /usr/bin). You could also try that one instead of ditto.

[RunDontStop]

I keep trying and won't give up until I get a script executed by Switch. In the debug all I see is outcode 255. I have even removed variables just to get something. This is the script

$!/bin/bash
sed "s/\&/PLEASE/g" /Users/switchuser/Desktop/sampletext.txt >> /Users/switchuser/Desktop/PLEASE.txt

I run just the command line in Terminal and it works – it takes sampletext.txt, replaces "&" with "PLEASE" and I end up with a new file PLEASE.txt. But when I try to use Switch to do it, using the .sh file, no result. With this flow having no variables I just have the output set to Original. My goal is to get the text file on the Desktop, but use Switch to do it. Maybe there is a permissions problem. I have run the chmod command on the script. I will keep working at this.

I have also tried running the script using terminal, with sh and path to script. I get a message:

The default interactive shell is now zsh

Then when I close the terminal window it creates PLEASE.txt – sometimes. This is aggravating, knowing the command is valid but not being able to execute it through a script.

There is something basic I am missing here. It's like Switch is not allowed to run the script (I think). And terminal does not produce an immediate result either.

[RunDontStop]

Figured it out - had $ in the shebang line instead of #. Working now. This is great and thank you.

[RunDontStop]

Update on the unzip problem:

From the beginning, the problem was the Unarchive app fails sometimes - it either goes to Problem jobs, or the result is incomplete. I am running version 10 of Unarchive.

Usually when these problem zips are opened with the Mac app Archive Utility, they unzip. So the question is - how do you get Switch to use this app in the event the Unarchive app fails?

The best answer is by using Execute Command as Freddy suggested.

Here is what makes zips a little weird compared to other input output workflows. When you open a zip with Archive utility, the zip remains intact in its original form. You have the unzipped result in the same directory as that zip. So where you started with one item, you end up with two items.

The trick is to deliver the result at the end of the flow. The following describes what I have now. It seems to work well.

The flow starts out and there is a loose zip file.

Immediately I send this to assemble job, arbitrary files, 1. The result of course is a folder that contains the zip, and nothing else.

This is what goes to Execute Command. The .sh file is as follows:

#!/bin/bash
open -W "${1}"/*.zip
osascript -e 'tell application "Finder" to close window 1'

In the Execute command app I have the argument "%1". I have the output as "Updated original job". I also have the processing as serialized, although it might not need to be.

You might ask - why not use the Mac command unzip, instead of open (which launches Archive Utility). But in my testing the unzip is not working with certain zip files, while open seems to unzip just about anything.

I am happy to say it is working. If you think about it, you have at the output folder after Execute command, a folder containing the original zip and the unzipped result. This is easily dismantled. You can send the original zip on to Recycle, and you have you unzipped output ready to go on to whatever flow or task you need.

Here is another consideration. The Archive Utility must not only open – it also needs to finish the task. You might have a monstrous size zip that takes a long time. What to do? You could add a long sleep to the end of the script.. My problem with that is that almost all zip files will unzip very quickly, and it seems ridiculous to have all jobs rest for an excessive amount of time because of the occasional big zip. I thought about having big zips over a certain size directing to a different Execute Command that points to a different .sh with a much longer sleep value.

So – isn't there a simple way to let the app finish? In the command line I tell the Mac to open any zip in the containing folder (*.zip). This launches the default app Archive Utility. So the open command at that point is complete. But the work is not complete. Luckily, Archive Utility always quits once it is finished. So I think that the "-W" in the script is an argument telling the script to wait until the app has quit. In my testing this seem to allow for large zips to go through the flow.