Re: [PATCH] tar: support the common file extensions .tlzma and .txz
On Wed, Feb 29, 2012 at 9:03 PM, Lauri Kasanen cur...@operamail.com wrote: The attached patch adds support for .txz and .tlzma tar archives. For .txz the proper way would be to add the magic detection The autodetection should already work, see archival/tar.c: Using git master: $ ./busybox tar tvf /tmp/test.txz tar: invalid tar magic Renaming the file to .tar.xz lets bb tar read it. I am not convinced .txz and .tlzma extensions are common. (In my opinion, existence of .tgz extension was a mistake). They exist, and GNU tar handles them, so I think bb tar shouldn't puke when it sees one. Busybox does handle .tgz and .tbz2, because they have the magic detection already written (xz magic is marked todo in archival/libarchive/get_header_tar.c). I consolidated several copies of autodetection code. One in get_header_tar.c is gone. Now tar recognizes XZ-compressed data using generic setup_unzip_on_fd(). I added a testsuite entry which verifies that. Please try current git. Please also review last ~5 commits, maybe I added a few bugs :( -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] tar: support the common file extensions .tlzma and .txz
On Tue, Mar 6, 2012, at 17:02, Denys Vlasenko wrote: I consolidated several copies of autodetection code. One in get_header_tar.c is gone. Now tar recognizes XZ-compressed data using generic setup_unzip_on_fd(). I added a testsuite entry which verifies that. Please try current git. Please also review last ~5 commits, maybe I added a few bugs :( Thanks, it works well now. Didn't catch anything reading the last few commits. - Lauri -- http://www.fastmail.fm - Same, same, but different... ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] tar: support the common file extensions .tlzma and .txz
Thanks, it works well now. Didn't catch anything reading the last few commits. I ran cppcheck on the affected files, and it found one possibly uninitialized use: [decompress_bunzip2.c:156]: (error) Uninitialized variable: runCnt Also, seems the __KERNEL__ ifdefs in the unxz code could be removed? - Lauri -- http://www.fastmail.fm - Does exactly what it says on the tin ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: printf problem interpreting octal escape sequences
Sorry for pushing this, but there has been traffic on the list, but no reaction to my inquiry. If I was unclear of information is missing, please let me know. Or at least say something like: POSIX says octal escape sequences are no longer than three digits, so even though dash and bash support four digits and BB echo does too, we will not introduce this behaviour to BB printf. Then at least I know that you regard the inquiry as invalid. It is not urgent, I just do not want it to be forgotten or forget it myself. Thank you. Alexander Kriegisch, 04.03.2012 00:49: Oh, I forgot: echo -n does not have this problem: $ echo -en '\057usr\057bin\n' /usr/bin $ echo -en '\0057usr\0057bin\n' /usr/bin Alexander Kriegisch, 04.03.2012 00:45: $ uname -a Linux fb7270 2.6.19.2 #1 Fri Feb 24 02:09:03 CET 2012 mips GNU/Linux $ busybox --help | head -n 1 BusyBox v1.19.4 (2012-03-01 12:42:09 CET) multi-call binary. # Okay $ printf %b '\057usr\057bin\n' /usr/bin # Not okay $ printf %b '\0057usr\0057bin\n' 7usr7bin Maybe somebody can fix this? If I can provide more info, please let me know. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: printf problem interpreting octal escape sequences
# Okay $ printf %b '\057usr\057bin\n' /usr/bin # Not okay $ printf %b '\0057usr\0057bin\n' 7usr7bin Looks like %b shall accept '\0d', '\0dd' and '\0ddd' sequences in argument strings (not in format strings). That's what the standard documents seem to define for printf. So the above is a bug in Busybox. Beside this octal constants in printf format strings and other argument strings (not %b) shall only accept '\d', '\dd' and '\ddd' sequences (without the leading zero). All this according to googled standards definitions. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
