Incorrect search filter: invalid characters - '
Archive-Unzip-Burst

 view release on metacpan or  search on metacpan

unzip-6.0/INSTALL  view on Meta::CPAN

    some of these may not be fully supported in future releases (or even
    in the current release).  Note also that very short command lines in
    MS-DOS (128 characters) may place severe limits on how many of these
    can be used; if need be, the definitions can be placed at the top of
    unzip.h instead (it is included in all source files)--for example,
    "#define MACRO_NAME", one macro per line.

      DOSWILD   (MS-DOS only)
        Treat trailing "*.*" like Unix "*" (i.e., matches anything); treat
        trailing "*." as match for files without a dot (i.e., matches any-
        thing, as long as no dots in name).  Special treatment only occurs
        if patterns are at end of arguments; i.e., "a*.*" matches all files
        starting with "a", but "*.*c" matches all files ending in "c" *only*
        if they have a dot somewhere before the "c".  [The default method of
        specifying files without a dot would be "* -x *.*", making use of
        UnZip's exclude-files option.]  The matching is actually the same as
        Unix, if you assume that undotted filenames really have an invisible
        dot at the end, which is how DOS and related systems treat filenames
        in general.  All other regular expressions (including "?" and
        "[range_of_chars]") retain their Unix-like behavior.

      WILD_STOP_AT_DIR   (incompatible with WINDLL!)
        Enables an additional option "-W".  When this qualifier is specified,
        the pattern matching routine is modified so that both '?' (single-char
        wildcard) and '*' (multi-char wildcard) do not match the directory
        separator character '/'. Examples:
          "*.c" matches "foo.c" but not "mydir/foo.c"
          "*/*.c" matches "bar/foo.c" but not "baz/bar/foo.c"
          "??*/*" matches "ab/foo" and "abc/foo" but not "a/foo" or "a/b/foo"
        To enable matching across directory separator chars, two consecutive
        multi-char wildcards "**" should be specified.
        This modified behaviour is equivalent to the pattern matching style
        used by the shells of some of UnZip's supported target OSs (one
        example is Acorn RISC OS).

      VMSWILD   (VMS only)
        Use parentheses rather than brackets to delimit sets (ranges), and
        use '%' instead of '?' as the single-character wildcard for internal
        filename matching.  (External matching of zipfile names always uses
        the standard VMS wildcard facilities; character sets are disallowed.)

      VMSCLI   (VMS only)
        Use VMS-style "slash options" (/FOOBAR) instead of the default Unix-
        style hyphenated options (-f).  This capability does not affect options
        stored in environment variables (UNZIP_OPTS or ZIPINFO_OPTS); those use
        the Unix style regardless.  Beginning with UnZip 5.32, the supplied
        VMS build methods generate both VMS-style and default "UNIX-style"
        executables; you should NOT add VMSCLI to the custom options.

      CHECK_VERSIONS   (VMS only)
        UnZip "extra fields" are used to store VMS (RMS) filesystem info,
        and the format of this information may differ in various versions
        of VMS.  Defining this option will enable UnZip warnings when the
        stored extra-field VMS version(s) do(es) not match the version of
        VMS currently being used.  This is a common occurrence in zipfiles
        received from other sites, but since the format of the filesystem
        does not seem to have changed in years (including on Alpha and
        IA64 systems), the warnings are not enabled by default.

      RETURN_CODES   (VMS only)
        VMS interprets return codes according to a rigid set of guidelines,
        which means it misinterprets normal UnZip return codes as all sorts
        of really nasty errors.  Therefore VMS UnZip returns an alternate set
        of return codes; since these may be difficult to interpret, define
        RETURN_CODES for human-readable explanations.

      VMS_TEXT_CONV   (everybody except VMS)
        VMS Stream_LF-format text files archived with the "-V" option
        (/VMS), but NOT with -VV (/VMS=ALL), should be fine when extracted
        on other systems.  Stream_LF-files archived with -VV should be
        readable as well, but they may get some junk appended.
        Text files with other formats (like the default VFC, with its
        embedded byte counts) may be only semi-readable at best when
        extracted on other systems.  Defining this option enables UnZip's
        -aa option to detect and convert VMS VFC-record text files into
        native text format.  Non-VMS UnZips now use a rudimentary VMS extra
        field analyser to relyably determine such text files. (Earlier
        versions of UnZip applied some heuristics instead.)
        Therefore this option is now enabled by default for the main program
        (but not the SFX stub), because it can be extremely useful on those
        rare occasions when a VMS text file must be extracted as normal text.

      USE_DJGPP_ENV   (MS-DOS DJGPP 2.0x only)
        Regular DJGPP v2.0x compiled programs which use ENVIRONMENT are
        able to read from the file "djgpp.env" as well as those set in the
        environment.  This adds about 1KB to the size of the executable.
        This option is disabled by default in Info-ZIP source. If you are
        able to use "djgpp.env" and don't like to clutter the environment
        with many special purpose variables, you may want to compile with
        this option set.

      USE_DJGPP_GLOB  (MS-DOS DJGPP 2.0x only)
        If you like to get UnZip binaries that handle command line arguments
        similar to Unix tools which are run in an Unix shell, you might want
        to set this compilation option.  This option enables the support for
        globbing command line arguments containing wildcards that is built
        into the DJGPP startup code.  When using a binary compiled with this
        option, you may have to enclose wildcard arguments in double quotes
        to get them passed to the program unmodified.  Enabling this option
        is not recommended, because it results in Info-Zip binaries that do
        not behave as expected for MS-DOS programs.

      USE_VFAT  (MS-DOS only, for using same executable under DOS and Win95/NT)
        djgpp 2.x and emx/gcc+RSX 5.1 can detect when they are running under a
        Win32 DOS box and will accordingly enable long-filename support.  For
        now only djgpp 2.x and emx/gcc with RSX 5.1 or later have this feature
        (and it is defined by default in msdos/makefile.dj2 and makefile.emx),
        but if/when other compilers build in similar support, define this
        macro to enable its use.  See also msdos/doscfg.h.  [Note that djgpp
        2.0's LFN support is flaky; users should upgrade to 2.01 or later.]

      NO_W32TIMES_IZFIX (Win32 including WinDLL, and WinCE)
        By specifying this option, you can disable Info-ZIP's special timestamp
        adjustment to get stable time stamps on NTFS disks that do not change
        depending on the current time being normal vs. daylight saving time.
        When this option is set, UnZip behaves exactly like other programs;
        file timestamps on NTFS partitions are created so that their >current<
        local time representation displayed by directory listings (cmd.exe
        "dir" command or Windows Explorer listings) is the same as shown by
        UnZip's listing. But the actual UTC timestamp values stored in the
        NTFS file attributes vary depending on whether extraction is done



( run in 0.778 second using v1.01-cache-2.11-cpan-acf6aa7dc9e )