![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ckuker.bwr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDTahoe / new / kermit|
Return to ckuker.bwr CVS log | Up to [CSRG BSD Unix] / 43BSDTahoe / new / kermit |
1.1 root 1: C-Kermit Version 4C(057):
2: Status, Bugs, and Problems
3: As of: 2 Aug 85
4:
5: Note: Version numbering system changed from decimal notation (like 4.2)
6: to number-letter notation (like 4C) to avoid confusion with Berkeley Unix
7: version numbers.
8:
9: See ckuker.upd for list of bugs already fixed.
10:
11: -- SUPPORT FOR DIFFERENT SYSTEMS: --
12:
13: 4.2BSD: "make bsd" works. Should work on VAX, SUN, Pyramid, & others.
14:
15: 4.1BSD: "make bsd" should work for this too (did not in C-Kermit v4.2).
16:
17: 4.3BSD: unknown, but "make bsd" should(!) work.
18:
19: 2.9BSD: Support in but untested: "make bsd29". Should be the same for 2.8.
20:
21: Version 7: works ok on the systems tested so far using "make v7", but some
22: fiddling with the make file is necessary for proc table definitions; see
23: the makefile and also ckuv7.hlp for details.
24:
25: PC/IX: should work ok with "make pcix".
26:
27: ATT 3Bx systems: should work ok with "make att3bx".
28:
29: Most other System V or System III based systems can build a working Kermit with
30: "make sys3"
31:
32: PDP-11's running a System III or V based Unix and which have no I & D space
33: should use "make sys3nid".
34:
35: DEC Pro-350 or -380 with Pro/Venix V2 (not V1) -- uses the regular "make sys3"
36: or "make sys3nid", but the file ckcfio.c might have to be edited first to
37: reduce the value of MAXWLD and/or SSPACE. See below under HINTS for details.
38:
39: For other Unix systems, see the makefile.
40:
41: VAX/VMS: support added by Stew Rubenstein at Harvard and Martin Minow at DEC.
42: Has to be built with CKV*.COM, needs development to handle all the VMS/RMS
43: features and to improve performance. Has its own build procedure. See
44: CKV*.*. VMS-specific bugs in CKVKER.BWR.
45:
46: Macintosh: Support added at Columbia, has own makefile, etc. See CKM*.*.
47:
48:
49: -- HINTS --
50:
51: - If the program dies with a message like "malloc fails in splitpath()"
52: whenever it tries to parse a filename (as in the "send" command), then
53: the amount of space allocated for filename expansion in the module
54: ckufio.c must be reduced. This can be done by changing the #defines
55: for MAXWLD (the maximum number of filenames) and SSPACE (the size of
56: static string space) to make the numbers smaller.
57:
58: - When modifying or writing KERMIT code, do NOT pass to a function
59: (e.g., "signal") the address of a static function. Doing so may
60: break VENIX code mapping. If you must pass the address of the
61: function, make it global and pick a "non-generic" name for it that
62: will hopefully be unique and yet informative.
63:
64:
65: -- BUG LIST --
66:
67: First, a disclaimer must be made. C-Kermit attempts to support all post-V6
68: Unix variations on all machines. This is a tall order, and requires careful
69: attention to certain details. As changes are made (and C-Kermit is still in
70: stage of fairly rapid development), there is always the chance that a change
71: -- made to introduce a new feature or fix a bug -- will not work as intended
72: on some systems, even though it was tested successfully on others. The main
73: area to watch out for is not system differences (which are handled fairly well
74: in the system-dependent ck?[ft]io modules), but in compiler differences,
75: especially int/char confusion. Characters should be stored in variables of
76: type char, not int, and char/int conversion should be avoided because of
77: problems introduced by sign extension. And i/o should not be used to read
78: characters into int variables, because the way in which the system stores the
79: character in an int varies from system to system (e.g. 68000s put them on the
80: left, the VAX on the right).
81:
82: If you have received a C-Kermit release that does not work correctly (except
83: for the bugs & restrictions noted below), it is not because the release was
84: not thoroughly test -- it was -- but because it was not tested on your system
85: since the last time changes were made, because of a lack of such a system to
86: test it on. If this happens to you, please try to track down the problem and
87: report as specifically as possible back to us.
88:
89:
90: General problems:
91:
92: - The program is too big, with too many features; source is too large to fit on
93: some disks. Needs to be reorganized so that a minimal Kermit can be built
94: for any system, and then frills can be added on if desired -- interactive
95: command parser, help strings, dial command, script command, etc.
96:
97: - There's not a full enough set of features available from command line
98: invocation. Commands like "bye" are missing. This is mainly to keep the
99: "kermit -h" help message small enough to fit on one screen.
100:
101: - Conditionalizations are not done clearly. In some cases it might be
102: better to have compile-time flags for features, rather than systems, or
103: generic system names, rather than specific vendor/machine names, to
104: avoid excessive nesting or repitition of compile-time variables.
105: Constructions like "#ifdef FOO | BAR" are avoided because many compilers
106: don't understand them; the alternative is to repeat code under different
107: conditionals (to accomplish an OR) or to include it within nested
108: conditionals (AND), sometimes applying De Morgan's law to achieve the
109: desired result...
110:
111: - Program's return code might be wrong in some cases (in 4.0, it was always
112: zero; in 4C some attempt is made to return correct codes for failure and
113: success).
114:
115: - On some systems (e.g. TRS-80 Model 16 with Xenix V7, or HP-9000 HP-UX)
116: C-Kermit reportedly runs VERY SLOWLY. The program could certainly do with
117: some tuning -- but not at the expense of modularity and transportability! --
118: but in the meantime, it can probably be sped up a lot by removing the
119: -DDEBUG from the makefile, eliminating hundreds of function calls, many of
120: them in critical code. Another speedup could come from allowing more
121: systems to take advantage of "myread()" -- the nonblocking version of
122: read(); see below.
123:
124: - Micros like the DEC Pro-350, when in "IBM mode" (set flow none, set
125: handshake xon), might not be able to keep up with incoming packets, even
126: at relatively low baud rates. The Pro-350 OS relies heavily on
127: XON/XOFF to avoid losing characters at the port, but XON/XOFF must be
128: disabled for communicating with IBM mainframes. The only solution is
129: to lower the packet size to 20 or 30 to reduce the probability that
130: data is lost in any particular packet, and maybe also reduce the baud rate.
131:
132: - Need 'set' command for retry-threshhold.
133:
134: - The program could be a little bit less cavalier in its treatment of files.
135: For instance, when receiving a file (with "warning" turned off) it will
136: overwrite any existing file of the same name. That's ok, but what if the
137: user types ^F or ^B to interrupt the transfer? This does not save the
138: existing file -- it's already been destroyed by the open() of the new copy,
139: which in turn is discarded as a result of the interruption. Maybe Kermit
140: should always make a temporary, unique name for incoming files, and then
141: rename them to their real names only after the transfer is complete. But
142: that's no good on systems (like the Macintosh) that don't have disk space
143: to burn.
144:
145: - Local versus remote mode is not, and probably can not, be determined
146: automatically upon startup. For instance, if you build Kermit with
147: "make sys3" on a 3B20 and a 3B2, the program has no way of knowing whether
148: it's running on a timesharing system (the 3B20, where it should be remote
149: by default) or a workstation (the 3B2, where it should be local by default).
150: If you find that Kermit comes up on your system in the wrong mode, you can
151: put the appropriate "set line" command in your .kermrc file -- "set line
152: /dev/tty" will always put you in remote mode.
153:
154: - Local mode file transfer display could be improved. On tty-style displays,
155: the "percent done" could be shown by doing something like
156: "0...1...2...3...4...5...6...7...8...9...".
157:
158: - If the program crashes or is halted (killed) from outside while it has the
159: terminal in a not-normal mode during command parsing or file transfer, the
160: terminal mode is not restored, and lock files are not cleaned up. There can
161: be no fix for this within C-Kermit itself.
162:
163: - The shell's interrupt, delete, and kill characters may interfere or
164: conflict with those used by the Kermit command parser. In any case, there
165: is no way to change Kermit's editing characters to conform to user's taste.
166:
167: - Status info should be updated only for real file transfers, not transactions
168: like "finish".
169:
170: - "!" command requires a space after, contrary to the Unix user's normal
171: expectation.
172:
173: - Many people have asked for a system-wide startup file similar to
174: the user's .kermrc file, perhaps with a conditional way to escape from
175: it if the user has her own .kermrc file. This notion might be extended
176: to include the entire hierarchy system -- home -- current directory.
177:
178: - A deeper problem with the initialization files is that the file is only
179: taken when the program enters interactive command dialog. To be consistent,
180: it should also be taken when the program is run via command line arguments.
181:
182: - Some users report that it would be more desirable to have an error during
183: execution of a take file return directly to command level, rather than
184: pop to the invoking take file (why?).
185:
186: - Some users report that the program should make no internal distinction
187: between running in foreground or background (why?).
188:
189: - Since kermit opens and closes the communication line with each command line
190: invocation, it is not convenient to use it in scripts in which it is
191: repeatedly invoked (e.g. a print spooler).
192:
193: - Variable names are sometimes confusing, especially the send/receive parameter
194: pairs (spsiz/rpsize, mystch/stchr, npad/mypadn, rtimo/timint, etc). This
195: is mostly history... they tend to agree with the names used in other Kermit
196: programs. Still, they should probably be changed. Ditto for some of the
197: procedure names.
198:
199: - Some C compilers do not support variable names longer than 6, nor function
200: names longer than 5, and some are not case sensitive (the DEC-20 C compiler
201: has all these restrictions, and the V6 Unix C compiler has some of them).
202: To ensure the widest possible portability, all identifiers should comply
203: with these restrictions -- currently many do not.
204:
205: - When the C-Kermit server is given a host command (or even some generic
206: commands like 'space'), it might have to think for a long time before
207: returning output. In this case, it should set a timer while waiting for
208: input from the fork and whenever the timer goes off, it should send a null
209: data packet to prevent the other Kermit from timing out.
210:
211: - When connecting back to C-Kermit after a transaction, or after finishing
212: the server, it may be necessary to type a ^Q to clear up an XOFF deadlock.
213: There's not much the Kermit program can do about this...
214:
215: - When interrupting a send with ^F or ^B, an appropriate message does not
216: seem to make it into the transaction log.
217:
218: ckufio.c:
219:
220: - ckufio currently goes to a lot of trouble to traverse the directory in
221: order to expand "*" and "?" in wildcards. Maybe it should just fork the
222: user's customary shell and have it do the expansion. This would allow
223: fancier filespecs to be given, like "~/ck*.[cwh]". But it would slow down
224: features like filename completion and menus in the interactive command
225: parser. (Find out how Unix FTP does it...)
226:
227: ckutio.c:
228:
229: - Myread() should be expanded to include systems that can't do nonblocking
230: reads, but can find out how many characters are in the input buffer -- this
231: would eliminate calling read() in a loop for each character during packet
232: transmission (e.g. Pro/Venix V1 could use "ioctl(x,TIOCQCNT,&y)", V7 could
233: use its buffer-queue-peeking trick, etc).
234:
235: - There should be a timed option for ttoc() for use during connect so you
236: can escape from XOFF'd or other stuck conditions.
237:
238: - There's no good way to select baud rates higher than 9600. Most Unix systems
239: don't supply symbols for them (unless you use EXTA, EXTB), and even when they
240: do, the program has no way of knowing whether a specific port serial
241: controller supports those rates.
242:
243: - Use of RAW|TANDEM in 4.1 BSD gives only unidirectional, not bidirectional,
244: flow control -- xoff's from the terminal are treated as data rather than
245: control signals. Symptom: possible loss of characters during CONNECT.
246:
247: - On some systems, there is an undesired interaction between the various
248: open() modes, fnctl(), and ioctl() invocations when modem-control lines
249: are involved. Some of this due to bugs in some Unix implementations or to
250: inconsistencies between them (e.g. as to the behavior of TIOCEXCL, etc).
251:
252: ckudia.c:
253:
254: - Some systems do not allow users to manipulate dialers directly.
255: - Should support a "phone book" (this would actually go in ckuus*.c).
256: - Pro/Venix V2 (and some other Sys V-based systems) are having DTR-dropping
257: problems when dialing. With Pro/Venix V2, a workaround is to get the system
258: to ignore the modem control signals and treat the line as a direct line by
259: issuing a "setline -d xxx" command, where "xxx" is the device node (e.g.
260: com1), rather than "setline -m xxx".
261: - Hayes modem dial string should be ATD, not ATDT, so that dialing will occur
262: in the mode that the modem is set up for (does everyone agree?).
263:
264: ckuus*.c:
265:
266: - The send command should have the same syntax as the get command to allow
267: multiple filenames to be given on a single line:
268:
269: send foo bar baz <-- send all these files
270: or:
271: send
272: Local file(s) to send: foo bar baz
273: Name(s) to send it/them under: x y z
274:
275: The latter form could be risky, of course, when mixed with wildcards,
276: and in any case would require major rewriting of many parts of the program
277: (which probably will never be done).
278:
279: - Baud rate selection currently requires user to type a number, which is
280: then verified against a system-dependent table. Better to have a baud rate
281: keyword (cmkey) table defined in the system-dependent module, so user
282: can abbreviate (e.g. '9' for '9600').
283:
284: - No way to put trailing comments on commands.
285:
286: - ckuus2.c makes the C optimizer run out of space under PC/IX and some other
287: systems.
288:
289: Protocol (ckcpro.w, ckcfn*.c):
290:
291: - No way to interrupt a protocol transaction until after it starts
292: successfully. For instance, no way to interrupt the timeouts and
293: retransmissions of the initial packet when the other side is not
294: responding, except for killing the whole program. Cure: check for
295: keyboard "interrupts" during the send-init process, set c[xz]seen.
296: But doing this will make the state table a lot more complicated...
297: Maybe change ^C trap to get back to command mode rather than exit
298: the program.
299:
300: - When parity is in use and the other Kermit cannot do 8th bit prefixing,
301: the user is not warned that binary files will not be transferred correctly.
302: This can be easily remedied by calling screen(SCR_WM,...) after the
303: send-init exchange has occurred, but this would make a dialog box pop
304: up during protocol on the Macintosh...
305:
306: ckucon.c:
307:
308: - Doesn't do any particular kind of terminal emulation. It wasn't meant to.
309: Filters can be used for this. Or a replacement module can be written
310: (as has been done for the Macintosh).
311:
312: - When sending BREAK, should clear output buffer first (this is done in BSD,
313: should be added for other systems to ttsndb() in ckutio.c).
314:
315: - Performance is poor on systems that can't check the input buffer or
316: do nonblocking read() calls. See the horrendous code that was added for V7
317: to get around this (peeking into tty buffers in kernel memory).
318:
319: - As structured, connect mode can't include commands to toggle logging on
320: and off or to change settings, because the fork that reads keyboard input
321: doesn't share variables with the fork that does port i/o.
322:
323: - The program may become stuck if the two sides get into an XOFF deadlock.
324: There should probably be a timer around (or in) the ttoc() call.
325:
326: - Reportedly, a control-S typed at the keyboard doesn't always seem to "take"
327: when doing terminal emulation under Pro/Venix V2 (DEC micros, terminals,
328: devices, systems are notorious for their insistence on doing XON/XOFF and
329: attendant problems. Remember the VT180?)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.