stew doesn't recognize shortened tbz extension

[gdevenyi]

btop releases "tbz" which are ".tar.bz" files but stew thinks its a binary

https://github.com/aristocratos/btop/releases/tag/v1.4.0

[marwanhawari]

Unfortunately, this is a limitation of the unarchive library I'm using (mholt/archiver@v3). Although it's now deprecated and he has a new library (mholt/archives). I'm not sure if migrating to the new library would solve this problem, but it might be worth exploring, especially because someone opened another issue here w/ regards to xz format.

This line is returning isArchive as false. Even if we manually override tbz files, the actual unarchiving library will throw an error here.

[strawhat-dev]

If anyone is interested in a workaround right now that will work with pretty much anything, I have set up a fork that just simply replaces the usage of the Go library for handling arhchives with the Unarchiver (external command).

The downside is that it requires an external dependency and spawns another process for the commands, i.e. unar & lsar on your PATH. (not even sure if this warrants a PR since this kills the whole single app executable portability thing, and I'd assume the owner would want any dependency, if required, to be a Go library)

On the positive side it is crossplatform and available on most package managers (e.g. pacman -Syu unarchiver for archlinux, brew install unar for macOS, scoop install unar for Windows), and that the lsar command (included with unar) will always reliably detect if a file is an archive and the unar command will always reliably (recursively) unarchive like anything anything you throw at it (in my experience).

Although 7zip may be slightly more robust, it doesn't automatically do recursive extraction and I've found the usage of unar to be far simpler, replacing any other CLI tool (e.g. 7z, tar, unzip, etc.) for my general purpose all-in-one decompression needs.

Also correctly handles xz archive issue ...