home *** CD-ROM | disk | FTP | other *** search
- 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 diffs or other files to Info-ZIP.
-
-
- 1 - "NO FEELTHY TABS"
-
- Many editors and e-mail 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 Maxe-mail offline email editor for one.)
-
- Bottom line: use spaces, not tabs.
-
- Related utility programs: Unix, OS/2 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, OS/2 and MS-DOS; Unix "tr".
-
- 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). [These exceptions may not exist anymore; Jean-loup now handles
- such things...]
-
-
- 3 - "NO FEELTHY HEX"
-
- We'll use uuencode/uudecode compatible converters to move binary files
- through our 7-bit e-mail systems (xxencode on special request; Mark's "ship"
- within Info-ZIP). Uuencoded files, if larger than +/- 32KB, will be broken
- into smaller (< 32KB) files (via David M. Read's UUXFER utility). If Down
- Under is involved, files will be broken into under-20KB chunks.
-
- 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. (That is,
- 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), .zoo (ver-
- sion 2.10, available for Unix, OS/2, MS-DOS, VMS, etc.), or .zip format.
- (If requesting we e-mail 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: zoo, tar, compress, gzip, zip, unzip.
- MS-DOS: ZOO, PKUNZIP, PAK, TAR, COMPRESS, and others.
-
-
- 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.ext" 8-dot-3 format). MacUsers, giggle
- all you want, but no spaces.
-
- Reason: Compatibility with different file systems. MS-DOS is the
- most limited, with the exception of CompuServe (6.3, argh).
-
-
- 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). [Sigh... -CN]
-
- 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 e-mail 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. We'd rather not
- have your C source file broken up into a dozen separate untitled messages,
- thank you.
-
-
- *-------------------*
-
- David Kirschbaum
- former Info-ZIP Coordinator
-
- with minor updates by Cave McNewt, 23 Jan 94.
-