Hopelessly Copy-Pasted (Buggy) and LONG ungzip and untar

They said it couldn't be done and would take forever to run on a ComputerCraft computer. Well, that's not so! Now you can finally open up 7-Zip (shameless plug for my favorite archiver) or Terminal and tar gibberish to compress and archive your files over for transit!

I originally started this project to get past a server's HTTP API ban (using MineCopy) so that my files would take much less long to get sent over. Then I added the tar functionality so I could send multiple files at once (and increase overall compression efficacy). So here goes:

This package contains a whole bunch of junk that will shamelessly pollute your global namespace, thanks to its copy-paste origin.
It includes a Pythonic option parser (read up on optparse), a bit library, a library to calculate CRC-32 digests, the lovely DEFLATE library, and finally the untar functionality. Please remember that because of the copy-pasty nature of the program, it heavily assigns to the global namespace (just look at the beginning) and is filled with countless shims. The program WILL run on your standard computer Lua 5 installation, with the exception of the untar functionality not working with any directory other than the current working directory.

A few useful functions:
local opt = optparse().OptionParser{usage, version}
local DEFLATE = deflatelua()
DEFLATE.gunzip(input=,output=,disable_crc=)

Check out the source for more! A simple loadfile() will load this.

Download:
http://pastebin.com/SA3FBVMR

NOTE: PLEASE MINIFY BEFORE PUTTING ONTO SERVERS. I CANNOT DO SO BECAUSE THAT WOULD BE VIOLATING THE LICENSES OF THE CONTAINED SOFTWARE.

NotSwedishFish, on 15 August 2016 - 11:33 PM said:

This package contains a whole bunch of junk that will shamelessly pollute your global namespace, thanks to its copy-paste origin.

Could you not work around this, by wrapping the code within separate functions and assigning a separate environment?

Truth be told, os.loadAPI() does pretty much exactly that for you.

The problem with os.loadAPI is that you need to reboot the computer once you've made changes to the file that you're referencing. I suppose I could've added "local" in front of some of the functions, but the main problem is that it contains many shims between CC's weird fs, io, and even os (no os.exit, so I mapped it to error) APIs to the standard Lua ones. For example, binary files can be read with "*a" or "*all" in my installation of Lua, but can only be read one byte at a time in CC (and in a different format – string vs number). I had to add in lots of io stuff like io.stdin, io.stderr (just redirect to stdout), and io.stdout.

NotSwedishFish, on 16 August 2016 - 04:53 PM said:

The problem with os.loadAPI is that you need to reboot the computer once you've made changes to the file that you're referencing.

Sorry, not sure I can figure out where this idea's coming from? If you modify an API file and wish to reload it, no reboots are required: you merely load it again.