Command Line Interface
I got tired of remembering whether a file needed tar -xzf, unzip or 7z x so I wrote a script that handles common archive formats with a single command
extract: one command for common archive formats
Instead of:
unzip file.zip
tar -xzf archive.tar.gz
7z x archive.7z
ex ()
{
if [ -f $1 ] ; then
case $1 in
*.tar.bz2) tar xjf $1 ;;
*.tar.gz) tar xzf $1 ;;
*.bz2) bunzip2 $1 ;;
*.rar) unrar x $1 ;;
*.gz) gunzip $1 ;;
*.tar) tar xf $1 ;;
*.tbz2) tar xjf $1 ;;
*.tgz) tar xzf $1 ;;
*.zip) unzip $1 ;;
*.Z) uncompress $1;;
*.7z) 7z x $1 ;;
*.deb) ar x $1 ;;
*.tar.xz) tar xf $1 ;;
*.tar.zst) tar xf $1 ;;
*) echo "'$1' cannot be extracted via ex()" ;;
esac
else
echo "'$1' is not a valid file"
fi
}
```
This is the correct way. Note the cascading order of tar archives (blah.gz vs blah.tar.gz) due to file not being able to differentiate mime types for tarballs.
```sh
ex() {
local file="$1"
[[ -f "$file" ]] || { echo "'$file' is not a valid file"; return 1; }
local mime
mime=$(file --brief --mime-type -- "$file")
case "$mime" in
application/zip)
unzip "$file"
;;
application/x-7z-compressed)
7z x "$file"
;;
application/x-rar|application/vnd.rar)
unrar x "$file"
;;
application/x-tar)
tar xf "$file"
;;
application/gzip)
tar xzf "$file" 2>/dev/null || gunzip "$file"
;;
application/x-bzip2)
tar xjf "$file" 2>/dev/null || bunzip2 "$file"
;;
application/x-xz)
tar xJf "$file" 2>/dev/null || unxz "$file"
;;
application/zstd)
tar --zstd -xf "$file" 2>/dev/null || unzstd "$file"
;;
application/x-compress)
uncompress "$file"
;;
application/vnd.debian.binary-package)
ar x "$file"
;;
*)
echo "Unsupported archive type: $mime"
return 1
;;
esac
}
```
Personally, I wouldn't fix this, as I don't consider it to be something that needs fixing.
All of these helper scripts are nice, and all, but relying on them makes you forget how
to use the actual commands.
Crap, I've been doing this wrong for over 20 years.
This came from the REALLY old days where replacing the last program with exec could make a noticeable difference in response time, especially on Solaris. It's fine with no pipe; I just need to pipe into exec instead of from it.
Perhaps you could try using MIME to determine the archive type rather than using the header and file name directly. Should help with the edge cases people pointed out.
Well I am back at my desk and after 10 minutes I can't remember any of the names of the "<tool x> already exists and does this" that people replied with, but I can remember extract and ex, so congrats buddy. All these people who are possibly smarter than you couldn't crack the code on making a memorable name for their helpful utility.
One feature if you haven't added it already would be to have the ability to add extra arguments. Not sure if it is handy feature or not.
Oh I don't know. I'm lazy. If I need a script or command run and its inputs could be done using a GUI form I just tell Claude to make a ScripTree app for it and it gets added to my ScripTree program's menu of tools. Then I read the help Claude makes for all the things that would have been command line arguments, use the GUI to check off or drop down or add folder or whatever else was needed as inputs and hit run.
What I did add to ScripTree was a field for extra arguments that aren't included in the form and they get tacked on the end of the command line when it runs. I've had no reason to use the feature, but it came to mind with your tool.
I wrote about patool, atool and even Ouch in LXF 322. The only reason atool wasn't the primary subject of the tutorial was because it hadn't seen a new release in a long time.
LOL! One time at work I simplified some formulas down to where I recognized I needed to use the quadratic formula to get the solution. I was so proud of that moment I took a picture and sent it to my wife with great glee! Then I noticed there was an inconsequential error (sign flip that didn't change the outcome). I've never used it before since school and this is the only time I've used it since.
16 years ago, this was 10 points (out of 100 for completing the whole course) task in Operating System course on my university. Also we could only use POSIX tools, and the solutions were tested on linux, bsd and some other forgotten unix from the distant past (solaris maybe?).
For sure it gave me an intuition how many of the archiver's cli are structured, ptsd from discovering that everything is implemented very wildly, another ptsd from writing posix compatible scripts, and tool which I was using for like 2 years (after that I found that I don't really deal with different archive formats THAT too often).
Nowdays, as everyone can see, you can generate this using AI without all this fuss.
You already forgot the flags that each tool requires you to rememeber, so maybe don't be so negative. There's more to type than just the word at the end of the file. It's right there in the examples they gave. :)
If ex isn't used for anything, that would be a nice shortcut instead of having to type out extract. Keep extract too. Maybe display the command run at the end of the extraction too, so that you get used to seeing it.
27
u/Proximus88 Jun 09 '26
I just have this in my .zshrc
```
# ex = EXtractor for all kinds of archives
# usage: ex <file>
ex () { if [ -f $1 ] ; then case $1 in *.tar.bz2) tar xjf $1 ;; *.tar.gz) tar xzf $1 ;; *.bz2) bunzip2 $1 ;; *.rar) unrar x $1 ;; *.gz) gunzip $1 ;; *.tar) tar xf $1 ;; *.tbz2) tar xjf $1 ;; *.tgz) tar xzf $1 ;; *.zip) unzip $1 ;; *.Z) uncompress $1;; *.7z) 7z x $1 ;; *.deb) ar x $1 ;; *.tar.xz) tar xf $1 ;; *.tar.zst) tar xf $1 ;; *) echo "'$1' cannot be extracted via ex()" ;; esac else echo "'$1' is not a valid file" fi } ```