view release on metacpan or  search on metacpan

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

     hdr/dfile.h

This is also how the zipfile directory appears.

And in DOS/OS2/NT

    Makefile
    src\afile.c
    src\docs\prog.txt
    hdr\cfile.h         .. etc

And in VMS      (we SHOUT in VMS and have a silly file system)

    MAKEFILE
    [SRC]AFILE.C
    [SRC.DOC]PROG.TXT
    [HDR]CFILE.H        .. etc
                        (OK VMS purist, [.SRC] etc. Only an example)

And in SMS/QDOS (quiet again, but slightly ludicrous !)

    Makefile
    src_afile_c
    src_doc_prog_txt
    hdr_cfile_h         .. etc

The main problem regarding SMS/QDOS is not that of extensions - (after
all, only VMS and DOS _really_ have extensions; Unix, AmigaDOS, NT and
OS/2 (and Win95) allow multiple '.' in.long.file.names.

The SMS/QDOS problem is that '_' is both a legal file name character
and a directory separator. This creates the difficulties, as
directories and files are somewhat different objects.

It is the intention that these versions of SMS/QDOS Zip/UnZip will
follow the Info-ZIP rules, thus providing compatibility with the other
platforms. It is possible to zip the file structure described above on
SMS/QDOS and unpack it on VMS and get the VMS structure as shown in the
example (and vice-versa). [We only choose the most obtuse file
systems for the examples].

In order to achieve this, SMS/QDOS names are mapped into Unix-style
ones when the zipfile is created and un-mapped when it is unpacked.
There is an option to unpack in 'zipfile' format (i.e. with '.' rather
than '_'), but there will be no option to pack to all '_'. That would
contravene the standard.  However, a file

        src_split_name_c        (which is src->split_name_c !)
                                          src/split_name.c)

where src is a hard directory, would be stored in the zip directory as

      src/split_name.c

It does handle '_' with a little intelligence.

The default UnZip option will be to translate '.' to '_'; this is
because there are still many QDOS/Minerva users that cannot handle '.'
without quotes, which is immensely inconvenient. For many SMS users
'_' is also the most natural and convenient option. It also means that
SMS/QDOS <-> SMS/QDOS Zip - UnZip sequences are transparent.

There will, however, be two ways around this in UnZip.

      1. It is possible to Config the UnZip default to be '.'
         translations (or not).

      2.  The UnZip -Q1 option will toggle the default (Config'ed)
          state.

Examples:

Given that we want/have

     Makefile                   (Makefile)
     src/afile.c                (src_afile_c)
     src/bfile.c                (src_bfile_c)
     src/docs/prog.txt          (src_docs_prog_txt)
     hdr/cfile.h                (hdr_cfile_h)
     hdr/dfile.h                (hdr_dfile_h)

Then on SMS/QDOS we might have added the *.c files as

     ex zip;'-r test *_c'

(or VMS, just to do something different)

    zip -r test [.src]*.c

In both cases the file lists as above (left).

To unpack on SMS/QDOS (just the _c/.c files)

   ex unzip;'test src/*.c'

   (and VMS, unzip test src/*.c)

i.e. in both cases using the 'zipfile' format. As a concession to
SMS/QDOS, you could also have:

   ex unzip;'test src_*_c'

        but not unzip test [.src]*.c on VMS !!!!! Sorry, dinosaurs.

Both SMS/QDOS commands unpack to

     src_afile_c etc, where src_ is a hard sub-directory.

(and the VMS example would unpack to [.src]afile.c, (or to src\afile.c on
DOS/NT/OS2 etc).

Options & SMS/QDOS Features
---------------------------

The options supported by Zip/UnZip are basically those documented in
the Info-ZIP documents and shown in on-line 'usage'. In particular, -r
and -j work as intended.

PLEASE NOTE: Previous SMS/QDOS zip/unzips have NOT followed these
conventions, for example -r was not implemented and -j was reversed.