ziprules

汇编代码大全

Subject: Info-ZIP Rules (No Feelthy ...)

In discussions with Mark Adler (and others), I realized we in the Info-ZIP
community have been evolving a set of rules that maybe oughtta be
documented, archived, and available to potential contributors.

The following appear to meet our requirements.  Please observe these
rules when submitting source, context diff, or other files to Info-ZIP.


1 - "NO FEELTHY TABS"

    Many editors and EMail systems either have no capability to use and/or
display the Ascii 9 TAB character correctly, or there are variable tab
columns, or other horrors.  (My MaxEMail offline email editor for one.)

    Bottom line:  use spaces, not tabs.

    Related utility programs:  Unix and MS-DOS :  expand, unexpand.
MS-DOS: Buerg's TABS; Toad Hall's TOADSOFT.  And some editors have the
conversion built-in.

    Exceptions:  The Unix Makefile.  Some makes seem to require "real"
tabs.  If they need it there, fine.  So don't fiddle the Makefile.


2 - "NO FEELTHY CRS"

    All source, documentation and other text files shall have Unix style
line endings (LF, Ctrl-J), NOT the MS-DOS CR/LF or Mac CR line endings.

    Reason:  "Real programmers" in any environment can convert back and
forth between Unix and DOS/Mac style.  MS-DOS Turbo C can use Unix or
MS-DOS line endings (donno about Mac Turbo C).  Buerg's LIST file display
utility for MS-DOS can use Unix or MS-DOS line endings.  Unix utilities
like diff and patch die a horrible death (or produce horrible output) if
target files have CRs.

    Related utilities:  flip for Unix and MS-DOS.

    Exceptions:  The zip archive README and zip.doc files, which Mark
Adler wants to leave in MSDOS for "unsophisticated" (read brain-dead) DOS
users.  Also the batch files to compile under MS-DOS (where it requires
the CRs.)


3 - "NO FEELTHY HEX"

    We'll use uuencode/uudecode compatible converters to move binary files
through our 7-bit EMail systems (xxencode on special request).  Uuencoded
files, if larger than +/- 32Kb, will be broken into smaller (< 32Kb)
files (via David M. Read's UUXFER utility).

    Reason:  to prevent sounds of gagging mailers from resounding
throughout the land.  To be standard with the Uunet side of the world.
To be relatively efficient in the binary->Ascii conversion.  (Yeah, yeah,
I know, there's better conversions out there.  But not as widely known.)

    Related utilities:  uuencode, uudecode, uuxfer20, quux, others.
Just make sure they don't leave imbedded or trailing spaces.  (E.g., they
should use the "`" character in place of Ascii 32.)  Else mailers are
prone to truncate or whatever.  Message me if you need one.


4 - "NO FEELTHY TARS"

    unzip will be available in .tar.Z (16-bit compressed tar), .arc (as
available on Unix, SIMTEL20, PKPAK, etc., *NOT* the latest proprietary
SEA version), or .zip format.  (If requesting we EMail you source,
specify desired format.)  zip source will only be distributed in .zip
archives.

    Reason:  For unzip development or use, anyone should have one of the
specified dearchivers.  For zip development or use, you shouldn't be
messing with zip unless you can already unzip.  (This protects the
innocent.)

    Related utilities:  Unix:  arc, tar, compress, zip, unzip.  MS-DOS:
PKUNPAK, PKUNZIP, PAK, TAR, COMPRESS, and others.

    Exceptions:  EMail me directly for any special circumstances or
requirements (zoo, BinHex, 12-bit compress, etc.)


5 - "NO FEELTHY FANCY_NAMES"

    Assume the worst:  that someone on a brain-damaged DOS system has to
work with everything your magic fingers produced.  Keep the file names
unimaginative and within MS-DOS limits (e.g., ordinary A..Z, 1..9, "-$_!"
type characters, in the "filename.typ" 8-dot-3 format).  MacUsers, giggle
all you want, but no spaces.

    Reason:  Compatibility with different file systems.  MS-DOS is the
most limited.


6 - "NO FEELTHY GRAPHICS"

    Do all your editing in a plain-text ASCII editor.  No WordPerfect,
Word, WordStar document mode, or other word processor files, thenkyew.
No desktop publishing.  No TIFFs, no GIFs, no imbedded pictures or dancing
ladies (too bad, Cave Newt).

    Reason:  Compatibility with different consoles.  My old XT clone is
the most limited!

    Related utilities:  vi, ed, EDLIN, Turbo C editor, UED, EASYEDIT, cat
or "COPY CON UNZIP.C"; various word processor -> text conversion utilities.


7 - "NO FEELTHY DASHES"

    Don't have repeated dashes (starting at the left margin) in any
source code or patches you try to EMail to me or Info-ZIP.  Instead, be
sure to always prefix them with a space, asterisk, comment, whatever, like
this:
#---------------   or
/*--------------   or even
 ---------------   (just indented)

    Reason:  Most "undigestify" utilities (that break down newsletters
into their separate messages) use that "--------" (starting at the left
margin) as the symbol that it's hit the end of a message.  I'd rather not
have your C source file broken up into a dozen separate untitled messages
in my mail system, thank you.  I'll be going through the unzip source Any
Day Now and changing anything like that by indenting, prefixing, whatever.


*-------------------*

David Kirschbaum
Info-ZIP Coordinator