view release on metacpan or  search on metacpan

unzip-6.0/proginfo/ZipPorts  view on Meta::CPAN

      comments (I think); etc.

      Related utilities:  vi, emacs, EDLIN, Turbo C editor, other programmers'
      editors, various word processor -> text conversion utilities.


  (4) NO FEELTHY LEFT-JUSTIFIED DASHES

      Always precede repeated dashes (------) with one or more leading non-
      dash characters:  spaces, tabs, pound signs (#), comments (/*), what-
      ever.

      Reason:  sooner or later your source file will be e-mailed through an
      undigestifier utility, most of which treat leading dashes as end-of-
      message separators.  We'd rather not have your code broken up into a
      dozen separate untitled messages, thank you.


  (5) NO FEELTHY FANCY_FILENAMES

      Assume the worst:  that someone on a brain-damaged DOS system has to
      work with everything your magic fingers produced.  Keep the filenames
      unimaginative and within MS-DOS limits (i.e., ordinary A..Z, 1..9,
      "-$_!"-type characters, in the 8.3 "filename.ext" format).  Mac and
      Unix users, giggle all you want, but no spaces or multiple dots.

      Reason:  compatibility with different file systems.  MS-DOS FAT is the
      most limited, with the exception of CompuServe (6.3, argh).

      Exceptions:  slightly longer names are occasionally acceptable within
      OS-specific subdirectories, but don't do that unless there's a good
      reason for it.


  (6) NO FEELTHY NON-ZIPFILES AND NO FEELTHY E-MAIL BETAS

      Beta testers and developers are in general expected to have both
      ftp capability and the ability to deal with zipfiles.  Those without
      should either find a friend who does or else learn about ftp-mailers.

      Reason:  the core development team barely has time to work on the
      code, much less prepare oddball formats and/or mail betas out (and
      the situation is getting worse, sigh).

      Exceptions:  anyone seriously proposing to do a new port will be
      given special treatment, particularly with respect to UnZip; we
      obviously realize that bootstrapping a completely new port can be
      quite difficult and have no desire to make it even harder due to
      lack of access to the latest code (rule 0.2).

      Public releases of UnZip, on the other hand, will be available in
      two formats:  .tar.Z (16-bit compress'd tar) and .zip (either "plain"
      or self-extracting).  Zip sources and executables will generally only
      be distributed in .zip format, since Zip is pretty much useless without
      UnZip.


  (7) NO FEELTHY E-MAIL BINARIES

      Binary files (e.g., executables, test zipfiles, etc.) should NEVER
      be mailed raw.  Where possible, they should be uploaded via ftp in
      BINARY mode; if that's impossible, Mark's "ship" ASCII-encoder should
      be used; and if that's unavailable, uuencode or xxencode should be
      used.  Weirdo NeXTmail, mailtool and MIME formats are also Right Out.

      Files larger than 50KB may need to be broken into pieces for mailing
      (be sure to label them in order!), unless "ship" is used (it can
      auto-split, label and mail files if told to do so).  If Down Under
      is involved, files must be broken into under-20KB chunks.

      Reasons:  to prevent sounds of gagging mailers from resounding through-
      out the land.  To be relatively efficient in the binary->ASCII conver-
      sion.  (Yeah, yeah, I know, there's better conversions out there.  But
      not as widely known, and they often break on BITNET gateways.)

      Related utilities:  ship, uuencode, uudecode, uuxfer20, quux, others.
      Just make sure they don't leave embedded or trailing spaces (that is,
      they should use the "`" character in place of ASCII 32).  Otherwise
      mailers are prone to truncate or whatever.


Greg Roelofs (a.k.a. Cave Newt)
Info-ZIP UnZip maintainer

David Kirschbaum
former Info-ZIP Coordinator