Improve support for compress tar files

[Gregg Young]

Missing bzip2.exe and gzip.exe are not reported for TAR.B/GZ files. AV2 may try to test with an archiver that doesn't exist when one that does exist is available or it may use the command line parameters from an older version with unknown consequences.

[Steven Levine]

fm/2 does not support compressed tar files in a generic fashion. This is not unexpected because archiver.bb2 was invented without compressed tar files in mind.

IMO, the correct solution is to enhance the archiver.bb2 format to allow us to name the compressor executable so that its exsistance can be checked for. This means an archiver.bb2 definition would now be 22 lines with line 22 naming the compressor executable. If needed we can add a line 23 to specify the switches to be passed to the compressor.

Another option is to fully implement the same recognition logic that tar supports. See section 8.1.1 of tar.info. The man page does not fully documented how this works. For example, the info doc lists

Suffix Compression program -------------------------------------------------------------- .gz gzip .tgz gzip .taz gzip .Z compress .taZ compress .bz2 bzip2 .tz2 bzip2 .tbz2 bzip2 .tbz bzip2 .lzma lzma .tlz lzma

as supported and the `--use-compress-program=PROG' option can handle almost anything else.

I don't think it's a good idea to add special case code to fm/2 if it can be avoided. We will never be able to handle all the possible special cases. The current special case code supports tar.bz but what about tar.xz and all the other compression methods that tar supports internally and externally. Like I said, I believe this is better handled in archiver.bb2.

[John Small]

As requested, I have uploaded my archiver.bb2 file.

[John Small]

John Small's ARCHIVER.BB2

[John Small]

Replying to stevenhl:

fm/2 does not support compressed tar files in a generic fashion. This is not unexpected because archiver.bb2 was invented without compressed tar files in mind.

IMO, the correct solution is to enhance the archiver.bb2 format to allow us to name the compressor executable so that its exsistance can be checked for. This means an archiver.bb2 definition would now be 22 lines with line 22 naming the compressor executable. If needed we can add a line 23 to specify the switches to be passed to the compressor.

Another option is to fully implement the same recognition logic that tar supports. See section 8.1.1 of tar.info. The man page does not fully documented how this works. For example, the info doc lists

Suffix Compression program -------------------------------------------------------------- .gz gzip .tgz gzip .taz gzip .Z compress .taZ compress .bz2 bzip2 .tz2 bzip2 .tbz2 bzip2 .tbz bzip2 .lzma lzma .tlz lzma

as supported and the `--use-compress-program=PROG' option can handle almost anything else.

I don't think it's a good idea to add special case code to fm/2 if it can be avoided. We will never be able to handle all the possible special cases. The current special case code supports tar.bz but what about tar.xz and all the other compression methods that tar supports internally and externally. Like I said, I believe this is better handled in archiver.bb2.

===

I agree completely, especially the comment that special case code like this is not a good idea.

[Gregg Young]

Ticket retargeted after milestone closed