Re: did tar(1) loose xz compression support in 11?
On Tue, 26 Aug 2014, Daniel Eischen wrote: On Tue, 26 Aug 2014, Tim Kientzle wrote: On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I can?t see any evidence in libarchive?s source that this ever worked. The man page is a little confusing. Here it says: --options options Select optional behaviors for particular modules. The argument is a text string containing comma-separated keywords and values. These are passed to the modules that handle particular formats to control how those formats will behave. Each option has one of the following forms: key=value The key will be set to the specified value in every module that supports it. Modules that do not support this key will ignore it. Then below, after the last option, it says: ... zip:compression=type Use type as compression method. Supported values are store (uncompressed) and deflate (gzip algorithm). If a provided option is not supported by any module, that is a fatal error. The first states that it is ignored, the latter states that it is a fatal error. The meaning of any module is subtle, at least for my feeble brain ;-) It suggests that options are passed to all modules, and each module is free to ignore options it does not understand. But at least one module must understand the option, or a fatal error is reported. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: did tar(1) loose xz compression support in 11?
On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I can’t see any evidence in libarchive’s source that this ever worked. However, there was some work done recently to improve error reporting from the options processor. It’s quite possible that —options xz:9 used to just be ignored and now it’s reporting an error. Tim On a hunch. I performed a similar test. I added STAGE to the following port. So I'll test here. # tar -cvJ --options xz:9 -f posadis-xz9.tar.xz ./posadis/ a ./posadis a ./posadis/files a ./posadis/pkg-plist a ./posadis/Makefile a ./posadis/distinfo a ./posadis/pkg-descr a ./posadis/files/patch-Makefile.in a ./posadis/files/patch-configure.in # tar -cvJ --options xz:1 -f posadis-xz1.tar.xz ./posadis/ a ./posadis a ./posadis/files a ./posadis/pkg-plist a ./posadis/Makefile a ./posadis/distinfo a ./posadis/pkg-descr a ./posadis/files/patch-Makefile.in a ./posadis/files/patch-configure.in unlike the previous examples, and arguments. I used the v switch. Presuming that would provide feedback on any anomalous usage. However. The following proves otherwise: # ls -la -rw-r--r-- 1 root wheel 2380 Aug 27 06:47 posadis-xz1.tar.xz -rw-r--r-- 1 root wheel 2380 Aug 27 06:47 posadis-xz9.tar.xz (performed on a RELENG_9 box) As one can see, nothing (compression level(s)) were UNchanged. So the verdict is in; the _recent_ changes provide the needed feedback where anomalous usage is concerned. Short version; tar now works correctly -- it's fixed. :) Humble opinion; the man(1) pages could be somewhat more concise. Humble request; would it be possible to make [bsd]tar(1) honor the short-hand version of options? Thank you, Tim, and everyone else, for all your thoughtful replies. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: did tar(1) loose xz compression support in 11?
On Wed, 27 Aug 2014, Warren Block wrote: On Tue, 26 Aug 2014, Daniel Eischen wrote: The man page is a little confusing. Here it says: --options options Select optional behaviors for particular modules. The argument is a text string containing comma-separated keywords and values. These are passed to the modules that handle particular formats to control how those formats will behave. Each option has one of the following forms: key=value The key will be set to the specified value in every module that supports it. Modules that do not support this key will ignore it. Then below, after the last option, it says: ... zip:compression=type Use type as compression method. Supported values are store (uncompressed) and deflate (gzip algorithm). If a provided option is not supported by any module, that is a fatal error. The first states that it is ignored, the latter states that it is a fatal error. The meaning of any module is subtle, at least for my feeble brain ;-) It suggests that options are passed to all modules, and each module is free to ignore options it does not understand. But at least one module must understand the option, or a fatal error is reported. Yes, I got that, but it is confusing when you are intentionally passing to only one module, as in the original post, xz:9, and considering that the fatal error and ignore it parts are listed in separate sections. Regardless, tar(1) has many options, so a little confusion is not unsurprising :-) -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
did tar(1) loose xz compression support in 11?
Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? Thank you for all your time, and consideration. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: did tar(1) loose xz compression support in 11?
On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV signature.asc Description: OpenPGP digital signature
Re: did tar(1) loose xz compression support in 11?
On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) Thank you, very much, Peter. For taking the time to respond. --Chris -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: did tar(1) loose xz compression support in 11?
Chris H bsd-li...@bsdforge.com writes: On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) I can't find any changes that would make the syntax change. At least, not in quite a long while. Therefore, this change may not be intentional. However, I looked at the the manual page from 9.3, and its description of the features looks the same as on the latest HEAD, and *doesn't* look like leaving out a key (in this case, compression-level) is ever compliant. You might try the latest (or older) libarchive from the ports, and compare its behaviour. Also, there are a number (amusingly many, in fact) of other ways of specifying these parameters that may be more convenient for you, so another look throught the tar(1) manual might save you a few minutes. Good luck. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: did tar(1) loose xz compression support in 11?
On Tue, Aug 26, 2014 at 1:23 PM, Lowell Gilbert freebsd-current-lo...@be-well.ilk.org wrote: Chris H bsd-li...@bsdforge.com writes: On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) I can't find any changes that would make the syntax change. At least, not in quite a long while. Therefore, this change may not be intentional. However, I looked at the the manual page from 9.3, and its description of the features looks the same as on the latest HEAD, and *doesn't* look like leaving out a key (in this case, compression-level) is ever compliant. You might try the latest (or older) libarchive from the ports, and compare its behaviour. Also, there are a number (amusingly many, in fact) of other ways of specifying these parameters that may be more convenient for you, so another look throught the tar(1) manual might save you a few minutes. Good luck. I've CCed kientzle@ for input. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: did tar(1) loose xz compression support in 11?
Chris H bsd-li...@bsdforge.com writes: On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) I can't find any changes that would make the syntax change. At least, not in quite a long while. Therefore, this change may not be intentional. However, I looked at the the manual page from 9.3, and its description of the features looks the same as on the latest HEAD, and *doesn't* look like leaving out a key (in this case, compression-level) is ever compliant. You might try the latest (or older) libarchive from the ports, and compare its behaviour. Also, there are a number (amusingly many, in fact) of other ways of specifying these parameters that may be more convenient for you, so another look throught the tar(1) manual might save you a few minutes. Thank you, Lowell. For your extremely informative reply. Curious. The man page I read from my freshly built 11-CURRENT indicates the following: xz:compression-level A decimal integer from 0 to 9 specifying the xz compres- sion level. As I have always read that (interpreted it). It meant: xz:decimal-number (0-9) Which is what I've always used. I haven't grepped ports||src yet. But if it makes any difference, it came from src -- build/install world. I'll do some poking around. But all my other boxes (RELENG_8 RELENG_9) use xz:decimal-number. Thanks again, Lowell. For taking the time to respond. Greatly appreciated. --Chris Good luck. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: did tar(1) loose xz compression support in 11?
Chris H wrote this message on Tue, Aug 26, 2014 at 16:32 -0700: Chris H bsd-li...@bsdforge.com writes: On 8/26/14 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I use: tar -cJ --options xz:compression-level=1 .. on head. Are you using the right syntax? Apparently not. Using your example works as expected. RELENG_8, and RELENG_9 use short-hand; tar -cvJ --options xz:9 Why/when the change to long-hand? Seems a shame. Now I get to modify all my scripts, and such. :P Altho I don't suppose it'd be a big deal to back out (revert) the changes made to tar(1). :) I can't find any changes that would make the syntax change. At least, not in quite a long while. Therefore, this change may not be intentional. However, I looked at the the manual page from 9.3, and its description of the features looks the same as on the latest HEAD, and *doesn't* look like leaving out a key (in this case, compression-level) is ever compliant. You might try the latest (or older) libarchive from the ports, and compare its behaviour. Also, there are a number (amusingly many, in fact) of other ways of specifying these parameters that may be more convenient for you, so another look throught the tar(1) manual might save you a few minutes. Thank you, Lowell. For your extremely informative reply. Curious. The man page I read from my freshly built 11-CURRENT indicates the following: xz:compression-level A decimal integer from 0 to 9 specifying the xz compres- sion level. As I have always read that (interpreted it). It meant: xz:decimal-number (0-9) Which is what I've always used. I haven't grepped ports||src yet. But if it makes any difference, it came from src -- build/install world. I'll do some poking around. But all my other boxes (RELENG_8 RELENG_9) use xz:decimal-number. Thanks again, Lowell. For taking the time to respond. Greatly appreciated. Could it be that previous versions were ignoring the option and not giving you an error? It looks like that was the case on my 9.1-PR box: $tar -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 38956 Aug 26 17:33 test.txz $tar --options xz:9 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 38956 Aug 26 17:33 test.txz $tar --options xz:1 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 38956 Aug 26 17:33 test.txz $tar --options xz:compression-level=1 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 41772 Aug 26 17:34 test.txz $tar --options xz:compression-level=9 -cJf test.txz *.patch *.c testcrypt *.h; ls -l test.txz -rw--- 1 jmg wheel 38956 Aug 26 17:34 test.txz -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: did tar(1) loose xz compression support in 11?
On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I can’t see any evidence in libarchive’s source that this ever worked. However, there was some work done recently to improve error reporting from the options processor. It’s quite possible that —options xz:9 used to just be ignored and now it’s reporting an error. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: did tar(1) loose xz compression support in 11?
On Tue, 26 Aug 2014, Tim Kientzle wrote: On Aug 26, 2014, at 11:05 AM, Chris H bsd-li...@bsdforge.com wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I can’t see any evidence in libarchive’s source that this ever worked. The man page is a little confusing. Here it says: --options options Select optional behaviors for particular modules. The argument is a text string containing comma-separated keywords and values. These are passed to the modules that handle particular formats to control how those formats will behave. Each option has one of the following forms: key=value The key will be set to the specified value in every module that supports it. Modules that do not support this key will ignore it. Then below, after the last option, it says: ... zip:compression=type Use type as compression method. Supported values are store (uncompressed) and deflate (gzip algorithm). If a provided option is not supported by any module, that is a fatal error. The first states that it is ignored, the latter states that it is a fatal error. The meaning of any module is subtle, at least for my feeble brain ;-) Also, the syntax for [lr]zip:compression=type is very clear, whereas the syntax for compression-level keys omit the =value. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org