gcc -o ViewLHA viewlha.c
The executable itself, however, is just a kickstarter for the real actor here: a script called 'vlha' that must be placed in S. This script is written for plain old AmigaOS 2, with a syntax for LHA which is very different from the one accepted by our version.
.key fname/a
;View a graphics file compressed with LhA
lha >NIL: -X x "<fname>" "<fname>" ram:t/
PPShow >NIL: "ram:t/<fname>"
delete >NIL: "ram:t/<fname>"
There are many issues here. First of all, simply using <fname> to accept a parameter wouldn't work on an AROS script. I had to modify the first line adding this:
.key fname/a
.BRA {
.KET }
then all <fname> occurriencies had been replaced with more friendly {fname}.
Second issue, our version of LHA neither accepts the -X switch, which basically allows to extract a file skipping its MS/DOS extension, nor can be used this way to decompress anything into the RAM:T drawer. So I had to find the proper way to do at least the latter action. About the former, I have to open a little chapter on its own. ViewLHA was originally meant to fullfit a very specific, very amigaish need: opening a single image compressed into a single LHA archive, as like as if it was a substitute for other real-time compressing tools, like PowerPacker on the Amiga or NTFS compression on Windows. Since on Amiga we don't need extensions at all in file names, the image would not have any, and the archive should have had a the same name of the image, with the .lha suffix. For instance, a command like:
ViewLHA pippo.lha
Would have opened with PPShow a image called "pippo", included in an archive called "pippo.lha" by temporarily store it in RAM:T. Although many people use LHA in a similar way to compress .mod files and distribute them on Aminet, single-file LHA archives are quite uncommon, specially for images. Moreover, AROS and Icaros are "nearer" to the PC world than classic Amiga computer ever did, so the use of .extensions in names is really common. I had to deal with these differences. My solution for the LHA line is the following:
lha -xw=t:{fname} "{fname}" >NIL:
-xw tells LHA to decompress the archive "{fname}" in the t:{fname} directory. You may notice the first instance is not included in double quotes, fact is that our LHA command does not like using them in that place. This might lead to issues with archives with spaces in their name, but frankly speaking I left this potential issue for a later time. Our pippo.lha contents, for instance, would be expanded in the dynamically created t:pippo drawer. Oddingly enough, the >NIL: redirector does not seem to work with LHA, which continues writing its output messages on stdout. I'll see later if another LHA option allows to shut its mouth completely.
Third issue, as far as I know we don't have PPShow for AROS. But this is really not an issue, since we have a gem called ZuneView which integrates a directory browser:
sys:utilities/zuneview/zuneview "t:{fname}" >NIL:
Obviously, once we have seen all images, we have to delete the temporary directory:
delete "t:{fname}" ALL FORCE
Was this enough? Not really. Our LHA produces archives with a slightly different filetype tag than the one used by Mats. For this reason, almost every archive I created for testing purpose wasn't recognized as a LHA archive by his tool. Luckily Mats is a very smart guy: not only he provided the sources, not only gave me permission to modify, adapt and distribute his scripts as I wished, but he also provided me the best possible collaboration. When he told me that «The modification to the signature checking is just a matter of checking for '-lh' at offset 2 in the file rather than '-lh5-'», I edited the viewlha.c file to replace "if (strncmp(buf + 2, "-lh5-", 5))" with "if (strncmp(buf + 2, "-lh", 3))", rebuilt the executable and, tah dah...
...it works like a charm!
Mats already promised enhancements to his program, like the ability to use wildcards in the command line and support for multiple file. I will follow his path as much as I can, but I already consider this result quite functional.
There's now a follow-up to this story!
Tomorrow, or later, I will also explain why I decided to replace the original 'ram:T/' reference with a simple T:, since it is another little option I decided to add to Icaros...
