I want to create an automator quick action to enable creation of tar archives using quick action menus on any selected file or folder. Do I have to use Apple Script or something else?
I am unable to do it. Someone please help.
Not sure why you’d want a tar archive rather than a standard gzip (for which there is already a “Compress” menu option), but anyway:
Automator’s Action documentation is crap, but it looks like the “Pass input as arguments” option passes absolute paths for the selected items as $1, $2, etc.
Once saved as a quick action, this should create a .tar file from the selected files in the current Finder folder. Finessing the shell script, which is crude[1][2], is left as an exercise for the reader.
–
[1] The archive’s file name is the just name of the first selected file with .tar appended, which is the second most lazy solution after just calling it “Archive.tar” (and potentially overwriting an existing file of the same name).
[2] The tar archive will replicate the full folder hierarchy, /Users/NAME/path/to/folder/…, whereas you probably just wanted a flat folder of files. Eh, but *nix shell makes everything painful.
I think the compress option currently existing gives zip file and not gzip. Kindly clarify.
The script given by you works even with only the second line used. Why to use the first line then?
How to get just the folder of files into tar, instead of the full hierarchy.
Basically I want to create tar.gz files which are created by feedback assistant app of iOS while submitting feedback.
the script shown on this page does not work.
http://hints.macworld.com/article.php?story=20100405082159362
You’re right. Compress produces .zip, not .tar.gz.
First line changes the working directory (initially your home folder). The original script writes the .tar archive to this folder.
You need to convert the array of absolute paths that Automator supplies to an array of file names. Various ways you can do that in shell languages, ranging from the obviously tedious to the concisely arcane. Stolen from the script you linked, here is the latter[1]:
cd `dirname "$1"`
tar -cz - "${@##*/}" > "$1".tar.gz
BTW, since all the paths are now relative to the current folder, you definitely need to set the working directory for this.
I also added a -z flag (because naturally a command named tar would have a gzip compressor built in, rather than, you know, just piping its output to gzip #SMH).
As for why the linked script doesn’t work, at a guess it’s probably a bash script which doesn’t work in zsh shell or vice-versa.[2] Change the Run Shell Script to use /bin/bash and see if that does it.
HTH
[1] This sort of nonsense is exactly why I despise 70s-era[3] shell languages—even Perl is more logical and learnable than this! The $@ gives you argv, which I understand (though why couldn’t it just be @ on its own?). The braces are just delimiters and probably unnecessary here. The ##*/ after it is hopelessly opaque, but I’m guessing says “for each string in the array, remove everything up to the last “/”. A proper array programming language would let you say something like (in hypothetical syntax) @ dirname, which is only a couple more characters to type and infinitely more readable, but that’s *nix CLI for you: just a dumpster fire of poorly thought out, poorly composable interfaces that, 50 years later, nobody can be bothered to fix.
[2] Yet another reason to despise 70s-era shell languages: there’s probably a dozen different (and naturally incompatible) shell languages, all doing the same job equally badly. I don’t disagree with Apple pulling the P* languages from stock macOS, painful as that removal is for certain users (sysadmins, mostly), but why couldn’t they have stripped out all the *nix junk too, starting with all the old crap shells that hardly anyone uses any more…
[3] It’s a pity Apple themselves don’t care about shell scripting or they could’ve gone with fish instead of zsh. It wouldn’t fix everything—the whole environment needs rebuilt from its untyped, untagged pipes upward for that—but would at least bring the UX up to the 1990s.
I tried changing to bash, zsh, but in both cases the script gave errors as per screen shot below if both lines are executed. However if only the first line is run it does not give any error.
cd `dirname "$1"`
tar -cz "${@##*/}" > "$1".tar.gz
The error remains irrespective if the “-” after “-cz” is removed or retained.
Please help.
My bad: for all the times I tell others off for not quoting shell code correctly, I did it myself. Line 1 should be:
cd "`dirname "$1"`"
Without the outer set of quotes, if `dirname "$1"` should return a path with spaces in it, the cd command will receive that as multiple arguments—not what you want! [1]
e.g. If $1 is the following path (note the space in the middle!):
/Users/foo/some folder/111.xslx
dirname "$1" will output:
/Users/foo/some folder
which is then passed to the cd command as two separate arguments, /Users/foo/some and folder!
Adding the outers set of quotes ensures that cd receives the single, correct argument:
"/Users/foo/some folder"
My mistake: I forgot backticks only execute their content, they do not quote its result. I didn’t notice it in testing because my own test folder was named “test”; had I named it “test folder”, I’d have discovered the bug myself.
Fingers crossed, once you make that fix to line 1, the script should now work as intended.
[1]Have I mentioned how much I despise *nix shell languages?
In my defense, *nix shell languages were devised by evil insane programmers utterly committed to making everyone’s lives as painful and miserable as inhumanly possible—and succeeded too, beyond even their own most demented, sadistic dreams. These langs are utterly bass-ackwards in design, their default behavior being to do what you almost never want instead of what you almost always need. The right design would be to expand variables and evals to a single quoted value by default, and provide an explicit “expand to array” operator for the very rare occasions the user does want a sequence of values.
This is why *nix neckbeards have so many “shooting yourself in the foot” jokes and think that they are very hilarious indeed.
Bad luck, but the script still gives the same error prompt even after correcting the first line.
I think the error is in line 2 because even after I delete line 1, the line 2 when run alone gives the same error prompt as with line 1 and line 2 run together.
Please help.
Beats me, as I cannot replicate that error here and the error message is typically unhelpful.
Does the action work okay for other files? Does it fail if you tar the 111.xlsx file directly in Terminal:
cd /path/to/your/folder
tar -c 111.xlsx > test.tar
Also worth googling “tar” and “bad file descriptor” to see if that provides clues, as that sounds a bit suspect. (stat is a command that gets information on a file—permissions, modification date, etc—so the error suggests there’s a problem accessing that file.)
Are all the selected files in the same folder?
I am selecting one file at a time and doing right click to choose quick action for tar. The error occurs for any file or multiple files within the same folder, when done Tar using your suggested commands in quick action.
However the commands work successfully if I use them directly in Terminal.
Can you post the full path to the file you’re tar-ing?
Full path to the file is as below.
/Users/sn/Downloads/111.xlsx
Oh-ho. That I can reproduce. Files in ~/Downloads always throw a stat: Bad file descriptor. Create a new Quick Action with the following script:
cd ~/Downloads
tar -c "111.xlsx"
Run this test action (doesn’t matter on what files), and it will fail with the same error. That points to it being a problem with Quick Actions, the Downloads folder, and tar.
Now create a normal workflow with the same script and run it in Automator. Automator may prompt you for permission to access your Downloads folder. Grant it. The file tars successfully.
Now go into System Preferences > Security & Privacy > Privacy > Files and Folders and remove Automator’s permission to access Downloads. Run the workflow again. It fails with a Bad file descriptor error.
Lastly, move the 111.xlsx file to your Home folder and compress it there. That works for me and confirms it.
…
Basically my shell code is perfect. It’s everything else about macOS that’s an absolute sack of spanners.
In this case, the problem is that the WorkflowServiceRunner process (which is what Finder launches in order to run your Quick Action) doesn’t appear to have the same full disk access that Finder has.
Nor does WorkflowServiceRunner display a dialog requesting permission to access that folder, so there’s no way for you to grant it. So when tar tries to access a file in Downloads, the WorkflowServiceRunner’s sandbox blocks it, causing the ancient gnarly tar (or, more specifically, the ancient gnarly OS-level POSIX APIs that tar uses to interact with the filesystem) to fail with an utterly unhelpful error message, when a modern simple “sandbox permission denied” message would’ve explained everything in an instant instead of days of blindly running around to figure it out.
Thank you, Apple, for wasting hours of our lives chasing after your bugs, stupids, and general failure of joined-up thinking. Jackasses.
(Honestly, if I I invoiced Apple for all of my time that it’s wasted over the years, I could buy a very nice house. In Manhattan.)
…
Since Automator.app is legacy-ware [over]due to be replaced by Shortcuts, there’s no point filing a bug report on an Automator-based Quick Action as Apple (rightly) WONTFIX it.
Instead, recreate your Quick Action in Shortcuts.app, and if your Shortcuts-based Quick Action throws the same error then do file a bug report on that. (And then post a copy of your bug report on openradar.me, and post the link to that copy here for everyone’s reference.)
…
Anyway, this is absolutely my last word on this topic. As every word I would normally be using at this point would be strictly four-letters and get me rapidly ejected from any family-friendly forum. However, if OP would like to show appreciation for my time, ten bucks punted to msf.org would be a nice gesture.
HTH
Thanks for the trouble.
However I failed to tar it using automator even after moving the file to different folders. I get the same error.
Nevertheless the shortcut for tar worked without problem. I will also not waste time over hitting my head on Automator script Quick Action.
Thanks once again.
Can you share the way you created the shortcut for tar?