z and z: A tale of two z’s

Remember my little rant from a few weeks ago, the one about single-character application names? If you don’t it’s just as well. I usually regret my rants. That one was no exception.

The point comes through though, since I have two z’s to report — this one and this one.

 

The z on the left is an intuitive compression-decompression tool. By all rights it should sense whether a file should be compressed or decompressed, and come up with the right results. If you remember atool or dtrx or unp, think of it as one of those, with enough smarts to do the opposite, if need be.

I did run into a few problems with z — the z on the left, that is. Compression seemed to sputter in the Arch version, while it looked for something called compress at /usr/bin/. It wasn’t finding it, and so half of what it could do, it couldn’t.

The z on the right is another fast directory switching tool. It’s by the same author as j and j2, and seems to follow the same pattern.

If you place the z.sh script somewhere in your $PATH, and change the $_Z_CMD variable to just “z”, then you should start building a database of recently visited directories. From there you can jump straight to a particular one by prefixing it — or part of it — with just “z”.

In theory, of course, and there is more to it than just that. It works acceptably well, although personally I’m not much of a fan of fast-directory-switcher-gizmos, and so a lot of it is probably lost on me.

So there are the two z’s, and I’d like to just take one last second to remind everyone out there who is working on building The Next Great Killer App, The Program That Will Change Life As We Know It, The Application That Consumed The Entire Universe In One Slobbery Gulp, to please — please — think rationally for just the briefest moment, and give your program a name that’s longer than just one stupid letter. 😡

unp: Boring is not always a bad thing

The Debian package pages say unp is a perl script that can unpack almost anything, provided you have the supporting formats installed in your system. In that way, it appears to be a lot like atool or dtrx, both of which we perused last year.

And this is where I run dry on things to say about unp. It has no color. It doesn’t do much other than rip files out and drop them in a folder.

It has a smaller set of specific flags that will fine-tune your decompression experience. And it seems proficient enough to know how to extract almost any type of archive; enter unp -s and it will tell you what it supports at any given moment.

But that’s all there is. Even the AUR version points at the Debian package page, which is rather boring. 😐

Ah well. It’s not always a bad thing to be boring. 😉

pigz: Equality among parallelized compression tools

Miguel called me out the other day, for including pbzip2 when I mentioned repeatedly that I wouldn’t include esoteric compression tools in this little adventure.

He’s right on the one hand, since pbzip2 — and now pigz — are specific to one particular algorithm. But they both do such cool things:

I don’t think I can add much more to the 1000 words that image is worth. Same flags and arrangement as pbzip2, only this time I used a 256Mb file of random characters, because I am impatient. 😈

I should offer the same caveat this time as I did last time: You may not see much improvement on a single-core machine.

And now for the daring feat of the day, jamming this, pbzip2 and parallel all into the same command …

ls random-{1,2}.txt | parallel pbzip2 -f -k -9 | parallel pigz -f -k -9

Let me just press enter and we’ll see if I spawn a singularity aga

pbzip2: The luxury of multiprocessing

This is one of those times when a screenshot will tell you a lot more than I can, with words:

pbzip2, the parallificated bzip2, chopping a good 20 seconds of the compression time on a 256Mb clump of random text.

In that situation, nothing else is running and this laptop has an SSD in it, so it’s fairly quick to start with. But pbzip2 still manages to slash the time it takes to smush it down a bit.

The fun part of pbzip2 is watching htop while it’s running. In the case of vanilla bzip2, the system load meter on one processor spikes to 100 percent, while the other sits near idle.

But pbzip2 kicks both of them up to max on this Core2 Duo, and the fan suddenly starts to whine a little louder. 😉

That does, of course, suggest that on a single core machine, you might not see any improvement at all. Logic says without an advanced CPU, there’s little space to share.

Give it a try and see what happens; you never know, there might be a tiny bump.

In closing, I’m a little surprised pbzip2 isn’t more famous. Perhaps there’s something sketchy in its history that I don’t know about.

For now, I’m going to tempt fate and try

ls random-{1,2}.txt | parallel pbzip2 -f -k -9

and see what happens. Yes, combining parallel and pbzip2 might just trigger a black hole in the center of my computer. But just let me press Enter now and see wha