[Toybox] [PATCH] Add the gzip/gunzip/zcat I wrote for toolbox.

[Rob Landley]

On 04/26/2017 05:03 PM, enh wrote:
> if you're actually going to start to look, i'll attach my port of the
> current toolbox implementation.

Ok, carving out a half hour to look at this... optargs should really
have [-123456789] at the end so "gzip -3 -9" is -9 but "gzip -9 -3" is
-3. While we're at it, OLDTOY() was there so these things could share
option strings, except why does zcat have -cd? (And the three main
functions... if oldtoy isn't handling this right it needs fixing. Do you
care about the standalone builds, by the way? that was always the
complicating part, chording together shared infrastructure...)

I need to spend a 3 day weekend fixing the help infrastructure so it can
do reasonable includes, the duplication of -c and -f help text here
pains me.

Ok, jumping down to main()... it seems like there should be a
first_bit() function in lib/lib.c. Throw it in locally and move it when
I find a second user. (Leaving it _not_ static to remind me about the
library collation next time I hunt around for non-static functions.)

Setting FLAG_c for no arguments can't be right, assuming gzip is doing
what I think it is...

  gunzip one.gz - three.gz < two.gz

And yes two gets output to stdout. So gunzip - writes "back" to stdout
automatically, so the loopfiles() behavior of "no arguments means one
argument equivalent to -" is fine and the callback has to handle that.

loopfiles() second argument is a function pointer, you don't need a
do_gz() wrapper you can just have the test in loopfiles to pass in the
right argument. (It's not changing partway through the loop...)

Hmmm, there's plumbing in things like patch and sed -i using
copy_tempfile() to create a temporary file we write to (and delete if
we're interrupted, via an atexit() variant). You're leaving the
half-finished output file if we get interrupted, is that what we should do?

Also, some commands go to a bit of trouble _not_ to exit immediately if
they hit an error in one of the arguments, but instead produce an error
message and continue on to the next argument. (This is why error_msg()
sets toys.exitval to 1 if it's not already set, so that when we _do_
eventually exit it records the error.)

Should gzip do that? You have it exiting immediately... Huh, it looks
like the gnu/gnu/gnu/dammit version _does_ exit at the first error,
which seems awkward and wrong. So this matches the existing version, the
question remains what the behavior _should_ be.

And I'm over my half hour with half the file left to go. And I haven't
even spliced in the deflate plumbing from compress yet. :)

Rob