![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ZipRules CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [MW Coherent from dump] / coherent / b / bin / unzip|
Return to ZipRules CVS log | Up to [MW Coherent from dump] / coherent / b / bin / unzip |
1.1 root 1: Subject: Info-ZIP Rules (No Feelthy ...)
2:
3: In discussions with Mark Adler (and others), I realized we in the Info-ZIP
4: community have been evolving a set of rules that maybe oughtta be
5: documented, archived, and available to potential contributors.
6:
7: The following appear to meet our requirements. Please observe these
8: rules when submitting source, context diff, or other files to Info-ZIP.
9:
10:
11: 1 - "NO FEELTHY TABS"
12:
13: Many editors and EMail systems either have no capability to use and/or
14: display the Ascii 9 TAB character correctly, or there are variable tab
15: columns, or other horrors. (My MaxEMail offline email editor for one.)
16:
17: Bottom line: use spaces, not tabs.
18:
19: Related utility programs: Unix and MS-DOS : expand, unexpand.
20: MS-DOS: Buerg's TABS; Toad Hall's TOADSOFT. And some editors have the
21: conversion built-in.
22:
23: Exceptions: The Unix Makefile. Some makes seem to require "real"
24: tabs. If they need it there, fine. So don't fiddle the Makefile.
25:
26:
27: 2 - "NO FEELTHY CRS"
28:
29: All source, documentation and other text files shall have Unix style
30: line endings (LF, Ctrl-J), NOT the MS-DOS CR/LF or Mac CR line endings.
31:
32: Reason: "Real programmers" in any environment can convert back and
33: forth between Unix and DOS/Mac style. MS-DOS Turbo C can use Unix or
34: MS-DOS line endings (donno about Mac Turbo C). Buerg's LIST file display
35: utility for MS-DOS can use Unix or MS-DOS line endings. Unix utilities
36: like diff and patch die a horrible death (or produce horrible output) if
37: target files have CRs.
38:
39: Related utilities: flip for Unix and MS-DOS.
40:
41: Exceptions: The zip archive README and zip.doc files, which Mark
42: Adler wants to leave in MSDOS for "unsophisticated" (read brain-dead) DOS
43: users. Also the batch files to compile under MS-DOS (where it requires
44: the CRs.)
45:
46:
47: 3 - "NO FEELTHY HEX"
48:
49: We'll use uuencode/uudecode compatible converters to move binary files
50: through our 7-bit EMail systems (xxencode on special request). Uuencoded
51: files, if larger than +/- 32Kb, will be broken into smaller (< 32Kb)
52: files (via David M. Read's UUXFER utility).
53:
54: Reason: to prevent sounds of gagging mailers from resounding
55: throughout the land. To be standard with the Uunet side of the world.
56: To be relatively efficient in the binary->Ascii conversion. (Yeah, yeah,
57: I know, there's better conversions out there. But not as widely known.)
58:
59: Related utilities: uuencode, uudecode, uuxfer20, quux, others.
60: Just make sure they don't leave imbedded or trailing spaces. (E.g., they
61: should use the "`" character in place of Ascii 32.) Else mailers are
62: prone to truncate or whatever. Message me if you need one.
63:
64:
65: 4 - "NO FEELTHY TARS"
66:
67: unzip will be available in .tar.Z (16-bit compressed tar), .arc (as
68: available on Unix, SIMTEL20, PKPAK, etc., *NOT* the latest proprietary
69: SEA version), or .zip format. (If requesting we EMail you source,
70: specify desired format.) zip source will only be distributed in .zip
71: archives.
72:
73: Reason: For unzip development or use, anyone should have one of the
74: specified dearchivers. For zip development or use, you shouldn't be
75: messing with zip unless you can already unzip. (This protects the
76: innocent.)
77:
78: Related utilities: Unix: arc, tar, compress, zip, unzip. MS-DOS:
79: PKUNPAK, PKUNZIP, PAK, TAR, COMPRESS, and others.
80:
81: Exceptions: EMail me directly for any special circumstances or
82: requirements (zoo, BinHex, 12-bit compress, etc.)
83:
84:
85: 5 - "NO FEELTHY FANCY_NAMES"
86:
87: Assume the worst: that someone on a brain-damaged DOS system has to
88: work with everything your magic fingers produced. Keep the file names
89: unimaginative and within MS-DOS limits (e.g., ordinary A..Z, 1..9, "-$_!"
90: type characters, in the "filename.typ" 8-dot-3 format). MacUsers, giggle
91: all you want, but no spaces.
92:
93: Reason: Compatibility with different file systems. MS-DOS is the
94: most limited.
95:
96:
97: 6 - "NO FEELTHY GRAPHICS"
98:
99: Do all your editing in a plain-text ASCII editor. No WordPerfect,
100: Word, WordStar document mode, or other word processor files, thenkyew.
101: No desktop publishing. No TIFFs, no GIFs, no imbedded pictures or dancing
102: ladies (too bad, Cave Newt).
103:
104: Reason: Compatibility with different consoles. My old XT clone is
105: the most limited!
106:
107: Related utilities: vi, ed, EDLIN, Turbo C editor, UED, EASYEDIT, cat
108: or "COPY CON UNZIP.C"; various word processor -> text conversion utilities.
109:
110:
111: 7 - "NO FEELTHY DASHES"
112:
113: Don't have repeated dashes (starting at the left margin) in any
114: source code or patches you try to EMail to me or Info-ZIP. Instead, be
115: sure to always prefix them with a space, asterisk, comment, whatever, like
116: this:
117: #--------------- or
118: /*-------------- or even
119: --------------- (just indented)
120:
121: Reason: Most "undigestify" utilities (that break down newsletters
122: into their separate messages) use that "--------" (starting at the left
123: margin) as the symbol that it's hit the end of a message. I'd rather not
124: have your C source file broken up into a dozen separate untitled messages
125: in my mail system, thank you. I'll be going through the unzip source Any
126: Day Now and changing anything like that by indenting, prefixing, whatever.
127:
128:
129: *-------------------*
130:
131: David Kirschbaum
132: Info-ZIP Coordinator
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.