On 01/08/2018 07:27 PM, enh wrote: > the tests were here but never merged: > http://lists.landley.net/pipermail/toybox-landley.net/2017-April/008962.html
Yeah, it's in my todo heap. The problem is it's testing that gzip and gunzip match, if both were doing "cat" it would pass. I'd like to test at least some of the time against canned data. I was also mentally comparing it against tests/files/bzcat where I have two archives with different kinds of failures I wanted bunzip2 to catch. (The bunzip2 tests use the blkid files, which are coincidentally bzipped. For gzip I'd have to add test data...) Still, better starting point than what's currently there I suppose. Applied... (Then there's "can gzip recreate this file exactly", which is fraught-ish because there's questions of dictionary flush timing in there which aren't in the spec. It's nice to be able to recreate a tarball with the same sha256 as other implementations, but how high a priority is that? Hmmm... I wonder what busybox does there...) > i did see the weird suffix addition stuff when i read the man page, > but since it was (a) the first time i'd heard of it in 25 years and > (b) disgusting, i thought i'd wait until someone actually needed it. > > likewise the ignoring errors. that seemed like a bug rather than a > feature until proven otherwise. The "zcat README" acting like cat is an artifact of using gzread() instead of inflate(). > but, yeah, i should have said so in TODO comments. (i thought i did > comment the former, but that may have been lost in the toybox > obfuscated c competition rewrite.) I'm working towards merging the builtin inflate implementation and promoting the command, but there's a filing issue where gzip wants to reach over and do deflate (gzip -d) and zip also needs both. I can either throw the shared plumbing in lib (which bunzip2 isn't) or I can put them together in the same toys/* file (inflate and deflate both, which is how ps.c and cp.c and such do it, but I like to keep source files under 1000 lines when possible and ps.c is unavoidably way over because it's got 5 commands in it, 2 of which are rather complicated...) (I'm not worried about "tar" because that should shell out and pipe through...) I also hacked up "compress.c" to let me use different header signatures (ala the zlib stuff used by git), and I'm kinda squinting at it to see if there's a clean way to do that to gzip. I suspect zcat should autodetect, but on the compression side... Hmmm. (One of my post-1.0 goals is adding enough git support that repo can 'git clone' the source packages it wants to build, and I am NOT sticking git plumbing in gzip.c...) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
