view release on metacpan or  search on metacpan

unzip-6.0/qdos/IZREADME.SMS  view on Meta::CPAN

a bit tricky, but given the example:

     test1_bas
     test2_bas
     dir1->demo1_bas            where -> indicates a sub dir
     dir2->demo2_bas

     ex zip;'ram2_test *_bas'
     just finds test1_bas, test2_bas

     ex zip;'-r ram2_test *_bas'
     recurses and finds all the files

You might think that

    ex zip;'-r ram2_test *_*_bas'

would just find the files in the subdirectories--well yes, but it will
also find very other sub-dir'ed _bas file on the disk too. This is
a feature.

The pattern matching supports Unix-style 'regex' so you could:

        ex zip;'ram2_test dir?_*_bas'
        or
        ex zip;'ram2_test dir[12]_*_bas


UnZip has now got a fixed -d option. This is used to specify the
directory to unpack the zipfile into, it must follow immediately
after the zip name.

        ex unzip;'ram2_test_zip -d ram3_ *_txt'

would unpack all *_txt files to ram3_ .

It is not necessary to set the default directory to pack files, Zip
will remove any device names (and store any hard directory names,
unless you zip -j).

        ex zip;'ram1_test flp1_*'

                ----->
                        adding: file.dat (deflated 50%)
                        adding: menu.rext # (deflated xx%)
                        adding: zip * (deflated yy%)
                        adding: hard_one (stored 0%)
                        adding: hard_one/stuff.bas (deflated ...)

Due to the way the file-mapping is implemented, it is not supported
over the nX_ type network device.

Config Options
--------------

A limited number of SMS/QDOS specific functions can be set using the
QJump Config program.

      For Zip:

      Timeout for interactive 'Press any key' prompt

       65535                  Wait forever      (aka -1)
       0                      No wait
       n (1-32767)            Wait for 'n' clocks (1/50 sec)

       Other values are unsupported. Note Config works on 'unsigned'
       integer values (at least according to my manual).

       Directory file type key.

       Config will accept any value in the range 3-255, known useful
       values are 3 (Thor), 4 (CST) and 255 (Level 2 devices). A value
       of 65535 (aka -1) means "determine from device info".

       For UnZip:

       Timeout as above

       Unpack mode (SMS/QOS ('_') or Info-ZIP ('.')

       List format (Info-ZIP ('.') or SMS/QDOS ('_')


When the 'Press a key' text is displayed, if you press ESC, then it
waits until you press any other key, infinite timeout. This may be
useful if you want (much) more time to study a listing etc.

Defaults for timeout and directory type are 250 and -1 respectively.

More Goodies
------------

Part of the Zip compression code is now in assembler; it runs
noticably faster than the previous version. Compressing some arbitrary
files with the previous Zip it took 251 seconds, with Zip 2.0.1 it
took (a mere) 170 seconds (68008 QL).

More good news is that SMS/QDOS is just another system option on top
of standard Info-ZIP, unlike the previous ports that were much more
SMS/QDOS specific. For example, compiling the standard source with c68
(i.e. #define QDOS), then you get an SMS/QDOS version.

Compile with Linux/gcc and get the standard Linux version. Now, here's
the cool bit; compile with Linux/gcc and "-DQLZIP", and get a standard
Linux Zip/UnZip with SMS/QDOS (header) extensions.

so, on Linux:

            zip -Q stuff.zip qtpi zip unzip

the -Q tells Zip to look for XTc68/Lux68 cross-compiler data size
blocks and produce a zipfile with SMS/QDOS headers in it (for exec
type programs). This works for exec files produced by the XTc68/Lux68
cross compilers and ANY SMS/QDOS files copied to a Unix or MS-DOS disk
from an SMS/QDOS floppy using 'qltools v2.2' (or later).

Self Extracting Archives
------------------------

Info-ZIP self-extracting archives (_sfx) are created in a rather
'brute-force' way. The UnZipSFX program is prepended to a zipfile.

i.e.          file_sfx = unzipsfx + file_zip
              ex file_sfx

Although the UnZipSFX program is a cut-down UnZip, it is still around
30Kb - 50Kb, depending on platform.

The success of this approach depends on how the operating system
loader loads executable files. On most systems where the loader only
loads the actual program part (Unix, VMS, DOS et al), the this is
quite efficient; if you make, say, a 4Mb zipfile and prepend a 30Kb
UnZipSFX image, then the system only loads the 30Kb program and the
process is efficient as the zipped data part is still unpacked from
disk. These systems also supply the running UnZipSFX program stub with
the path name of the file it was loaded from, so the program knows
what it has to unpack (so on Linux, for example):