On 3/14/19 1:00 PM, Rob Landley wrote: > On 3/14/19 12:08 AM, enh wrote: >> On Wed, Mar 13, 2019 at 4:05 PM Rob Landley <[email protected]> wrote: >> >> ((speaking of which, some of the tar tests are failing now.)) > > I usually consider "consumes its own output" to be "necessary but not > sufficient" as tests go: if it makes the same mistake at each end, we won't > catch it. So during development I've been testing that it can extract and > reproduce the linux-4.20.tar.gz tarball.
The next reason these are bad tests is they're not orthogonal. The first test is testing 37 things so if it doesn't work you have no idea why, and a single failure (in this case autodetection of decompression type when you didn't specify) makes pretty much all the tests fail. The autodetect issue is because if you "gzip blah.tar | tar xv" it won't autodetect because the input isn't seekable. It's silly to have stdin an a file treated differenty, but the implementation details of treating them the same are a bit funky because it reads the first tar record, and if it's not "ustar" it checks for bz2 and gz signatures, and... then what? You can fork a bzip2 or gzip process to inherit the filehandle but can't stick the 512 bytes of data BACK into it. On a seekable filehandle it seeks back before handing it over to the new process. On a nonseekable filehandle you have to fork a gratuitous process to cat the two input streams together. (It can sendfile() the second part but it's still there being a process until EOF. To do it gracefully I need a pipe unget ioctl, bug all I can find is messages on linux-kernel that say "oh wouldn't that be nice" and then not implementing it. I can do it with a tty, ioctl(TIOCSTI) albeit a byte at a time, but it's doable. But not for _pipes_ that I can find...) Anyway, that's why that part's not in this checkin yet. :) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
