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