2 [1]The Columbia Crown The Kermit Project | Columbia University
3 612 West 115th Street, New York NY 10025 USA o [2]kermit@columbia.edu
5 [3]Home [4]Kermit 95 [5]C-Kermit [6]Scripts [7]Current [8]New [9]FAQ
8 C-Kermit Program Logic Manual
11 [11]The Kermit Project
12 [12]Columbia University
14 As of: C-Kermit 9.0.300, 30 June 2011
15 Last update: Tue Jun 28 08:59:18 2011
17 IF YOU ARE READING A PLAIN-TEXT version of this document, note that
18 this file is a plain-text dump of a Web page. You can visit the
19 original (and possibly more up-to-date) Web page here:
21 [13]http://www.columbia.edu/kermit/ckcplm.html
23 [ [14]C-Kermit Home ] [ [15]Kermit Home ]
29 3. [18]SOURCE CODE PORTABILITY AND STYLE
31 4.A. [20]Group A: Library Routines
32 4.B. [21]Group B: Kermit File Transfer
33 4.C. [22]Group C: Character-Set Conversion
34 4.D. [23]Group D: User Interface
35 4.E. [24]Group E: Platform-Dependent I/O
36 4.F. [25]Group F: Network Support
37 4.G. [26]Group G: Formatted Screen Support
38 4.H. [27]Group H: Pseudoterminal Support
39 4.I. [28]Group I: Security
40 I. [29]APPENDIX I: FILE PERMISSIONS
44 The Kermit Protocol is specified in the book Kermit, A File Transfer
45 Protocol by Frank da Cruz, Digital Press / Butterworth Heinemann,
46 Newton, MA, USA (1987), 379 pages, ISBN 0-932376-88-6. It is assumed
47 the reader is familiar with the Kermit protocol specification.
49 This file describes the relationship among the modules and functions of
50 C-Kermit 5A and later, and other programming considerations. C-Kermit
51 is designed to be portable to any kind of computer that has a C
52 compiler. The source code is broken into many files that are grouped
53 according to their function, as shown in the [30]Contents.
55 C-Kermit has seen constant development since 1985. Throughout its
56 history, there has been a neverending tug-of-war among:
58 a. Functionality: adding new features, fixing bugs, improving
60 b. Adding support for new platforms.
61 c. "Buzzword 1.0 compliance".
63 The latter category is the most frustrating, since it generally
64 involves massive changes just to keep the software doing what it did
65 before in some new setting: e.g. the K&R-to-ANSIC conversion (which had
66 to be done, of course, without breaking K&R); Y2K (not a big deal in
67 our case); the many and varied UNIX and other API "standards"; IPv6.
69 [ [31]Contents ] [ [32]C-Kermit ] [ [33]Kermit Home ]
73 C-Kermit source files begin with the two letters "ck", for example
74 ckutio.c. Filenames are kept short (6.3) for maximum portability and
75 (obviously I hope) do not contain spaces or more than one period. The
76 third character in the name denotes something about the function group
77 and the expected level of portability:
79 a General descriptive material and documentation (text)
80 b BOO file encoders and decoders (obsolete)
81 c All platforms with C compilers (*)
83 e Reserved for "ckermit" files, like ckermit.ini, ckermit2.txt
87 i Commodore Amiga (Intuition)
91 m Macintosh with Mac OS 1-9
92 n Microsoft Windows NT/2000/XP
93 o OS/2 and/or Microsoft Windows 9x/ME/NT/2000/XP
94 p Plan 9 from Bell Labs
96 r DEC PDP-11 with RSTS/E (never used, open for reassigment)
97 s Atari ST GEMDOS (last supported in version 5A(189))
98 t DEC PDP-11 with RT-11 (never used, open for reassigment)
99 u Unix-based operating systems (*)
101 w Wart (Lex-like preprocessor, platform independent)
111 (*) In fact there is little distinction between the ckc*.* and cku*.*
112 categories. It would make more sense for all cku*.* modules to be
113 ckc*.* ones, except ckufio.c, ckutio.c, ckucon.c, ckucns.c, and
114 ckupty.c, which truly are specific to Unix. The rest (ckuus*.c,
115 ckucmd.c, etc) are quite portable.
117 One hint before proceeding: functions are scattered all over the ckc*.c
118 and cku*.c modules, where function size has begun to take precedence
119 over the desirability of grouping related functions together, the aim
120 being to keep any particular module from growing disproportionately
121 large. The easiest way (in UNIX) to find out in what source file a
122 given function is defined is like this (where the desired function is
127 This works because the coding convention has been to make function
128 names always start on the left margin with their contents indented, for
136 Also note the style for bracket placement. This allows bracket-matching
137 text editors (such as EMACS) to help you make sure you know which
138 opening bracket a closing bracket matches, particularly when the
139 opening bracket is above the visible screen, and it also makes it easy
140 to find the end of a function (search for '}' on the left margin).
142 Of course EMACS tags work nicely with this format too:
144 $ cd kermit-source-directory
147 Esc-X Visit-Tags-Table<CR><CR>
149 (but remember that the source file for ckcpro.c is [34]ckcpro.w!)
153 * Tabs should be set every 8 spaces, as on a VT100.
154 * All lines must no more than 79 characters wide after tab expansion.
155 * Note the distinction between physical tabs (ASCII 9) and the
156 indentation conventions, which are: 4 for block contents, 2 for
157 most other stuff (obviously this is not a portability issue, just
160 [ [35]Contents ] [ [36]C-Kermit ] [ [37]Kermit Home ]
162 3. SOURCE CODE PORTABILITY AND STYLE
164 C-Kermit was designed in 1985 as a platform-independent replacement for
165 the earlier Unix Kermit. c-Kermit's design was expected to promote
166 portability, and judging from the number of platforms to which it has
167 been adapted since then, the model is effective, if not ideal
168 (obviously if we had it all to do over, we'd change a few things). To
169 answer the oft-repeated question: "Why are there so many #ifdefs?",
172 * Many of them are related to feature selection and program size, and
173 so need to be there anyway.
174 * Those that treat compiler, library, platform, header-file, and
175 similar differences have built up over time as hundreds of people
176 all over the world adapted C-Kermit to their particular
177 environments and sent back their changes. There might be more
178 politically-correct ways to achieve portability, but this one is
179 natural and proven. The basic idea is to introduce changes that can
180 be selected by defining a symbol, which, if not defined, leaves the
181 program exactly as it was before the changes.
182 * Although it might be possible to "clean up" the "#ifdef mess",
183 nobody has access to all the hundreds of platforms served by the
184 #ifdefs to check the results.
186 And to answer the second-most-oft-repeated question: "Why don't you
187 just use GNU autoconfig / automake / autowhatever instead of
188 hard-coding all those #ifdefs?" Answers:
190 * The GNU tools are not available on all the platforms where C-Kermit
191 must be built and I wouldn't necessarily trust them if they were.
192 * Each platform is a moving target, so the tools themselves would
193 need to updated before Kermit could be updated.
194 * It would only add another layer of complexity to an already complex
196 * Conversion at this point would not be practical unless there was a
197 way to test the results on all the hundreds of platforms where
198 C-Kermit is supposed to build.
200 When writing code for the system-indendent C-Kermit modules, please
201 stick to the following coding conventions to ensure portability to the
202 widest possible variety of C preprocessors, compilers, and linkers, as
203 well as certain network and/or email transports. The same holds true
204 for many of the "system dependent" modules too; particularly the Unix
205 ones, since they must be buildable by a wide variety of compilers and
206 linkers, new and old.
208 This list does not purport to be comprehensive, and although some items
209 on it might seem far-fetched, they would not be listed unless I had
210 encountered them somewhere, some time. I wish I had kept better records
211 so I could cite specific platforms and compilers.
213 * Try to keep variable and function names unique within 6 characters,
214 especially if they are used across modules, since 6 is the maximum
215 for some old linkers (actually, this goes back to TOPS-10 and -20
216 and other old DEC OS's where C-Kermit never ran anyway; a more
217 realistic maximum is probably somewhere between 8 and 16). We know
218 for certain that VAX C has a 31-character max because it complains
219 -- others might not complain, but just silently truncate, thus
220 folding two or more routines/variables into one.
221 * Keep preprocessor symbols unique within 8 characters; that's the
222 max for some preprocessors (sorry, I can't give a specific example,
223 but in 1988 or thereabouts, I had to change character-set symbols
224 like TC_LATIN1 and TC_LATIN2 to TC_1LATIN and TC_2LATIN because the
225 digits were being truncated and ignored on a platform where I
226 actually had to build C-Kermit 5A; unfortunately I didn't note
227 which platform -- maybe some early Ultrix version?)
228 * Don't create preprocessor symbols, or variable or function names,
229 that start with underscore (_). These are usually reserved for
230 internal use by the compiler and header files.
231 * Don't put #include directives inside functions or { blocks }.
232 * Don't use the #if or #elif preprocessor constructions, only use
233 #ifdef, #ifndef, #define, #undef, and #endif.
234 * Put tokens after #endif in comment brackets, e.g. #endif /* FOO */.
235 * Don't indent preprocessor statements - # must always be first char
237 * Don't put whitespace after # in preprocessor statements.
238 * Don't use #pragma, even within #ifdefs -- it makes some
239 preprocessors give up.
240 * Same goes for #module, #if, etc - #ifdefs do NOT protect them.
241 * Don't use logical operators in preprocessor constructions.
242 * Avoid #ifdefs inside argument list to function calls (I can't
243 remember why this one is here, but probably needn't be; we do this
245 * Always cast strlen() in expressions to int:
246 if ((int)strlen(foo) < x)...
247 * Any variable whose value might exceed 16383 should be declared as
248 long, or if that is not possible, then as unsigned.
249 * Avoid typedefs; they might be portable but they are very confusing
250 and there's no way to test for their presence or absence at compile
251 time. Use preprocessor symbols instead if possible; at least you
252 can test their definitions.
253 * Unsigned long is not portable; use a preprocessor symbol (Kermit
254 uses ULONG for this).
255 * Long long is not portable. If you really need it, be creative.
256 * Similarly 1234LL is not portable, nor almost any other constant
257 modifier other than L.
258 * Unsigned char is not portable, use CHAR (a preprocessor symbol
259 defined in the Kermit header files) and always take precautions
260 against character signage (more about this [38]below).
261 * Don't use initializers with automatic arrays or structs: it's not
263 * Don't use big automatic arrays or structs in functions that might
264 be called recursively; some platforms have fixed-size stacks (e.g.
265 Windows 9x: 256K) and recursive functions crash with stack
266 overflow. Even when there is not a compiler limitation, this causes
267 memory to be consumed without bound, and can end up filling swap
269 * Don't assume that struct assignment performs a copy, or that it
271 * Don't use sizeof to get the size of an array; someone might come
272 along later and and change it from static to malloc'd. Always use a
273 symbol to refer to the array's size.
274 * Don't put prototypes for static functions into header files that
275 are used by modules that don't contain that function; the link step
276 can fail with unresolved references (e.g. on AOS/VS).
277 * Avoid the construction *++p (the order of evaluation varies; it
278 shouldn't but at least one compiler had a bug that made me include
280 * Don't use triple assignments, like a = b = c = 0; (or quadruple,
281 etc). Some compilers generate bad code for these, or crash, etc
282 (some version of DEC C as I recall).
283 * Some compilers don't allow structure members to have the same names
284 as other identifiers. Try to give structure members unique names.
285 * Don't assume anything about order of evaluation in boolean
286 expressions, or that they will stop early if a required condition
288 if (i > 0 && p[i-1] == blah)
290 can still dump core if i == 0 (hopefully this is not true of any
291 modern compiler, but I would not have said this if it did not
292 actually happen somewhere).
293 * Don't have a switch() statement with no cases (e.g. because of
294 #ifdefs); this is a fatal error in some compilers.
295 * Don't put lots of code in a switch case; move it out to a separate
296 function; some compilers run out of memory when presented with a
297 huge switch() statement -- it's not the number of cases that
298 matters; it's the overall amount of code.
299 * Some compilers might also limit the number of switch() cases, e.g.
301 * Don't put anything between "switch() {" and "case:" -- switch
302 blocks are not like other blocks.
303 * Don't jump into or out of switches.
304 * Don't make character-string constants longer than about 250 bytes.
305 Longer strings should be broken up into arrays of strings.
306 * Don't write into character-string constants (obviously). Even when
307 you know you are not writing past the end; the compiler or linker
308 might have put them into read-only and/or shared memory, and/or
309 coalesced multiple equal constants so if you change one you change
311 * Don't depend on '\r' being carriage return.
312 * Don't depend on '\n' being linefeed or for that matter any SINGLE
314 * Don't depend on '\r' and '\n' being different (e.g. as separate
316 * In other words, don't use \n or \r to stand for specific
317 characters; use \012 and \015 instead.
318 * Don't code for "buzzword 1.0 compliance", unless "buzzword" is K&R
319 and "1.0" is the first edition.
320 * Don't use or depend on anything_t (size_t, pid_t, etc), except
321 time_t, without #ifdef protection (time_t is the only one I've
322 found that is accepted everywhere). This is a tough one because the
323 same function might require (say) a size_t arg on one platform,
324 whereas size_t is unheard of on another; or worse, it might require
325 a totally different data type, like int or long or some other
326 typedef'd thing. It has often proved necessary to define a symbol
327 to stand for the type of a particular argument to a particular
328 library or system function to get around this problem.
329 * Don't use or depend on internationalization ("i18n") features,
330 wchar_t, locales, etc, in portable code; they are not portable.
331 Anyway, locales are not the right model for Kermit's
332 multi-character-set support. Kermit does all character-set
333 conversion itself and does not use any external libraries or
335 * In particular, don't use any library functions that deal with wide
336 characters or Unicode in any form. These are not only nonportable,
337 but a constantly shifting target (e.g. the ones in glibc).
338 * Don't make any assumption about signal handler type. It can be
339 void, int, long, or anything else. Always declare signal handlers
340 as SIGTYP (see definition in ckcdeb.h and augment it if necessary)
341 and always use SIGRETURN at exit points from signal handlers.
342 * Signals should always be re-armed to be used again (this barely
343 scratches the surface -- the differences between BSD/V7 and System
344 V and POSIX signal handling are numerous, and some platforms do not
345 even support signals, alarms, or longjmps correctly or at all --
346 avoid all of this if you can).
347 * On the other hand, don't assume that signals are disarmed after
348 being raised. In some platforms you have to re-arm them, in others
350 * Don't call malloc() and friends from a signal handler; don't do
351 anything but setting integer global variables in a signal handler.
352 * malloc() does not initialize allocated memory -- it never said it
353 did. Don't expect it to be all 0's.
354 * Did You Know: malloc() can succeed and the program can still dump
355 core later when it attempts to use the malloc'd memory? (This
356 happens when allocation is deferred until use and swap space is
358 * memset(), memmove(), and memcpy() are not portable, don't use them
359 without protecting them in ifdefs (we have USE_MEMCPY for this).
360 bzero()/bcopy() too, except we're guaranteed to have
361 bzero()/bcopy() when using the sockets library (not really). See
362 examples in the source.
363 * Don't assume that strncpy() stops on the first null byte -- most
364 versions always copy the number of bytes given in arg 3, padding
365 out with 0's and overwriting whatever was there before. Use
366 C-Kermit ckstrncpy() if you want predictable non-padding behavior,
367 guaranteed NUL-termination, and a useful return code.
368 * DID YOU KNOW.. that some versions of inet_blah() routines return IP
369 addresses in network byte order, while others return them local
370 machine byte order? So passing them to ntohs() or whatever is not
371 always the right thing to do.
372 * Don't use ANSI-format function declarations without #ifdef
373 CK_ANSIC, and always provide an #else for the non-ANSI case.
374 * Use the Kermit _PROTOTYP() macro for declaring function prototypes;
375 it works in both the ANSI and non-ANSI cases.
376 * Don't depend on any other ANSI preprocessor features like "pasting"
377 -- they are often missing or nonoperational.
378 * Don't assume any C++ syntax or semantics.
379 * Don't use // as a comment introducer. C is not C++.
380 * Don't declare a string as "char foo[]" in one module and "extern
381 char * foo" in another, or vice-versa: this causes core dumps.
382 * With compiler makers falling all over themselves trying to outdo
383 each other in ANSI strictness, it has become increasingly necessary
384 to cast EVERYTHING. This is increasingly true for char vs unsigned
385 char. We need to use unsigned chars if we want to deal with 8-bit
386 character sets, but most character- and string-oriented APIs want
387 (signed) char arguments, so explicit casts are necessary. It would
388 be nice if every compiler had a -funsigned-char option (as gcc
389 does), but they don't.
390 * a[x], where x is an unsigned char, can produce a wild memory
391 reference if x, when promoted to an int, becomes negative. Cast it
392 to (unsigned), even though it ALREADY IS unsigned.
393 * Be careful how you declare functions that have char or long
394 arguments; for ANSI compilers you MUST use ANSI declarations to
395 avoid promotion problems, but you can't use ANSI declarations with
396 non-ANSI compilers. Thus declarations of such functions must be
397 hideously entwined in #ifdefs. Example: latter:
398 int /* Put character in server command buffer */
403 #endif /* CK_ANSIC */
406 *srvptr = '\0'; /* Make sure buffer is null-terminated */
410 * Be careful how you return characters from functions that return int
411 values -- "getc-like functions" -- in the ANSI world. Unless you
412 explicitly cast the return value to (unsigned), it is likely to be
413 "promoted" to an int and have its sign extended.
414 * At least one compiler (the one on DEC OSF/1 1.3) treats "/*" and
415 "*/" within string constants as comment begin and end. No amount of
416 #ifdefs will get around this one. You simply can't put these
417 sequences in a string constant, e.g. "/usr/local/doc/*.*".
418 * Avoid putting multiple macro references on a single line, e.g.:
419 putchar(BS); putchar(SP); putchar(BS)
421 This overflows the CPP output buffer of more than a few C preprocessors
422 (this happened, for example, with SunOS 4.1 cc, which evidently has a
423 1K macro expansion buffer).
425 C-Kermit needs constant adjustment to new OS and compiler releases.
426 Every new OS release shuffles header files or their contents, or
427 prototypes, or data types, or levels of ANSI strictness, etc. Every
428 time you make an adjustment to remove a new compilation error, BE VERY
429 CAREFUL to #ifdef it on a symbol unique to the new configuration so
430 that the previous configuration (and all other configurations on all
431 other platforms) remain as before.
433 Assume nothing. Don't assume header files are where they are supposed
434 to be, that they contain what you think they contain, that they define
435 specific symbols to have certain values -- or define them at all! Don't
436 assume system header files protect themselves against multiple
437 inclusion. Don't assume that particular system or library calls are
438 available, or that the arguments are what you think they are -- order,
439 data type, passed by reference vs value, etc. Be conservative when
440 attempting to write portable code. Avoid all advanced features.
442 If you see something that does not make sense, don't assume it's a
443 mistake -- it might be there for a reason, and changing it or removing
444 is likely to cause compilation, linking, or runtime failures sometime,
445 somewhere. Some huge percentage of the code, especially in the
446 platform-dependent modules, is workarounds for compiler, linker, or API
449 But finally... feel free to violate any or all of these rules in
450 platform-specific modules for environments in which the rules are
451 certain not to apply. For example, in VMS-specific code, it is OK to
452 use #if, because VAX C, DEC C, and VMS GCC all support it.
454 [ [39]Contents ] [ [40]C-Kermit ] [ [41]Kermit Home ]
458 The C language and standard C library are notoriously inadequate and
459 unsafe. Strings are arrays of characters, usually referenced through
460 pointers. There is no native string datatype. Buffers are fixed size,
461 and C provides no runtime bounds checking, thus allowing overwriting of
462 other data or even program code. With the popularization of the
463 Internet, the "buffer exploit" has become a preferred method for
464 hackers to hijack privileged programs; long data strings are fed to a
465 program in hopes that it uses unsafe C library calls such as strcpy()
466 or sprintf() to copy strings into automatic arrays, thus overwriting
467 the call stack, and therefore the routine's return address. When such a
468 hole is discovered, a "string" can be constructed that contains machine
469 code to hijack the program's privileges and penetrate the system.
471 This problem is partially addressed by the strn...() routines, which
472 should always be used in preference to their str...() equivalents
473 (except when the copy operation has already been prechecked, or there
474 is a good reason for not using them, e.g. the sometimes undesirable
475 side effect of strncpy() zeroing the remainder of the buffer). The most
476 gaping whole, however, is sprintf(), which performs no length checking
477 on its destination buffer, and is not easy to replace. Although
478 snprintf() routines are starting to appear, they are not yet
479 widespread, and certainly not universal, nor are they especially
480 portable, or even full-featured.
482 For these reasons, we have started to build up our own little library
483 of C Library replacements, ckclib.[ch]. These are safe and highly
484 portable primitives for memory management and string manipulation, such
488 Like strncpy but returns a useful value, doesn't zero buffer.
497 Returns character as string
500 Used with ck?to?() as a safe sprintf() replacement for up to 4
504 Like ckmakmsg() but accepts up to 12 items
506 More about library functions in [42]Section 4.A.
508 [ [43]Contents ] [ [44]C-Kermit ] [ [45]Kermit Home ]
510 3.2. The "char" vs "unsigned char" Dilemma
512 This is one of the most aggravating and vexing characteristics of the C
513 language. By design, chars (and char *'s) are SIGNED. But in the modern
514 era, however, we need to process characters that can have (or include)
515 8-bit values, as in the ISO Latin-1, IBM CP 850, or UTF-8 character
516 sets, so this data must be treated as unsigned. But some C compilers
517 (such as those based on the Bell UNIX V7 compiler) do not support
518 "unsigned char" as a data type. Therefore we have the macro or typedef
519 CHAR, which we use when we need chars to be unsigned, but which,
520 unfortunately, resolves itself to "char" on those compilers that don't
521 support "unsigned char". AND SO... We have to do a lot of fiddling at
522 runtime to avoid sign extension and so forth.
524 Some modern compilers (e.g. IBM, DEC, Microsoft) have options that say
525 "make all chars be unsigned" (e.g. GCC "-funsigned-char") and we use
526 them when they are available. Other compilers don't have this option,
527 and at the same time, are becoming increasingly strict about type
528 mismatches, and spew out torrents of warnings when we use a CHAR where
529 a char is expected, or vice versa. We fix these one by one using casts,
530 and the code becomes increasingly ugly. But there remains a serious
531 problem, namely that certain library and kernel functions have
532 arguments that are declared as signed chars (or pointers to them),
533 whereas our character data is unsigned. Fine, we can can use casts here
534 too -- but who knows what happens inside these routines.
536 [ [46]Contents ] [ [47]C-Kermit ] [ [48]Kermit Home ]
540 When C-Kermit is on the far end of a connection, it is said to be in
541 remote mode. When C-Kermit has made a connection to another computer,
542 it is in local mode. (If C-Kermit is "in the middle" of a multihop
543 connection, it is still in local mode.)
545 On another axis, C-Kermit can be in any of several major states:
548 Reading and writing from the job's controlling terminal or
549 "console". In this mode, all i/o is handled by the Group E
550 conxxx() (console i/o) routines.
553 Reading and writing from the communicatons device. In this mode,
554 all i/o is handled by the Group E ttxxx() (terminal i/o)
558 Reading from the keyboard with conxxx() routines and writing to
559 the communications device with ttxxx() routines AND vice-versa.
561 When in local mode, the console and communications device are distinct.
562 During file transfer, Kermit may put up a file-transfer display on the
563 console and sample the console for interruption signals.
565 When in remote mode, the console and communications device are the
566 same, and therefore there can be no file-transfer display on the
567 console or interruptions from it (except for "in-band" interruptions
570 [ [49]Contents ] [ [50]C-Kermit ] [ [51]Kermit Home ]
572 4.A. Group A: Library Functions
574 Library functions, strictly portable, can be used by all modules on all
575 platforms: [52]ckclib.h, [53]ckclib.c.
577 (To be filled in... For now, see [54]Section 3.1 and the comments in
580 [ [55]Contents ] [ [56]C-Kermit ] [ [57]Kermit Home ]
582 4.B. Group B: Kermit File Transfer
584 The Kermit protocol kernel. These files, whose names start with "ckc
585 are supposed to be totally portable C, and are expected to compile
586 correctly on any platform with any C compiler. "Portable" does not mean
587 the same as as "ANSI" -- these modules must compile on 10- and 20-year
588 old computers, with C preprocessors, compilers, and/or linkers that
589 have all sorts of restrictions. The Group B modules do not include any
590 header files other than those that come with Kermit itself. They do not
591 contain any library calls except from the standard C library (e.g.
592 printf()). They most certainly do not contain any system calls. Files:
595 For use by C compilers that don't allow -D on the command line.
598 ASCII character symbol definitions.
601 System-independent signal-handling definitions and prototypes.
604 Originally, debugging definitions. Now this file also contains
605 all definitions and prototypes that are shared by all modules in
609 Kermit protocol symbol definitions.
612 Character-set-related symbol definitions (see next section).
615 The main program. This module contains the declarations of all
616 the protocol-related global variables that are shared among the
620 The protocol module itself, written in "wart", a lex-like
621 preprocessor that is distributed with Kermit under the name
624 [66]ckcfns.c, [67]ckcfn2.c, [68]ckcfn3.c
625 The protocol support functions used by the protocol module.
627 [69]Group B modules may call upon functions from [70]Group E, but not
628 from [71]Group D modules (with the single exception that the main
629 program invokes the user interface, which is in Group D). (This last
630 assertion is really only a conjecture.)
632 [ [72]Contents ] [ [73]C-Kermit ] [ [74]Kermit Home ]
634 4.C. Group C: Character-Set Conversion
636 Character set translation tables and functions. Used by the [75]Group
637 B, protocol modules, but may be specific to different computers. (So
638 far, all character character sets supported by C-Kermit are supported
639 in [76]ckuxla.c and [77]ckuxla.h, including Macintosh and IBM character
640 sets). These modules should be completely portable, and not rely on any
641 kind of system or library services.
644 Character-set definitions usable by all versions of C-Kermit.
647 Character-set definitions for computer "?", e.g. [79]ckuxla.h
648 for UNIX, [80]ckmxla.h for Macintosh.
651 Character-set translation tables and functions for computer "?",
652 For example, CKUXLA.C for UNIX, CKMXLA.C for Macintosh. So far,
653 these are the only two such modules. The UNIX module is used for
654 all versions of C-Kermit except the Macintosh version.
662 Here's how to add a new file character set in the original (non-Unicode
663 modules). Assuming it is based on the Roman (Latin) alphabet. Let's
664 call it "Barbarian". First, in ck?xla.h, add a definition for FC_BARBA
665 (8 chars maximum length) and increase MAXFCSETS by 1. Then, in
668 * Add a barbarian entry into the fcsinfo array.
669 * Add a "barbarian" entry to file character set keyword table,
671 * Add a "barbarian" entry to terminal character set keyword table,
673 * Add a translation table from Latin-1 to barbarian: yl1ba[].
674 * Add a translation table from barbarian to Latin-1: ybal1[].
675 * Add a translation function from Barbarian to ASCII: xbaas().
676 * Add a translation function from Barbarian to Latin-1: xbal1().
677 * Add a translation function from Latin-1 to Barbarian: xl1ba().
678 * etc etc for each transfer character set...
679 * Add translation function pointers to the xls and xlr tables.
681 Other translations involving Barbarian (e.g. from Barbarian to
682 Latin-Cyrillic) are performed through these tables and functions. See
683 ckuxla.h and ckuxla.c for extensive examples.
685 To add a new Transfer Character Set, e.g. Latin Alphabet 9 (for the
686 Euro symbol), again in the "old" character-set modules:
690 + Add a TC_xxxx definition and increase MAXTCSETS accordingly.
692 In ck?xla.h (since any transfer charset is also a file charset):
694 + Add an FC_xxxx definition and increase MAXFCSETS accordingly.
698 + Add a tcsinfo[] entry.
699 + Make a tcstab[] keyword table entry.
700 + Make an fcsinfo[] table entry.
701 + Make an fcstab[] keyword table entry.
702 + Make a tcstab[] keyword table entry.
703 + If necessary, make a langinfo[] table entry.
704 + Make entries in the function pointer arrays.
705 + Provide any needed functions.
707 As of C-Kermit 7.0, character sets are also handled in parallel by the
708 new (and very large) Unicode module, ckcuni.[ch]. Eventually we should
709 phase out the old way, described just above, and operate entirely in
710 (and through) Unicode. The advantages are many. The disadvantages are
711 size and performance. To add a character to the Unicode modules:
715 + (To be filled in...)
719 + (To be filled in...)
721 [ [84]Contents ] [ [85]C-Kermit ] [ [86]Kermit Home ]
723 4.D. Group D: User Interface
725 This is the code that communicates with the user, gets her commands,
726 informs her of the results. It may be command-line oriented,
727 interactive prompting dialog, menus and arrow keys, windows and mice,
728 speech recognition, telepathy, etc. The one provided is command-and
729 prompt, with the ability to read commands from various sources: the
730 console keyboard, a file, or a macro definition. The user interface has
731 three major functions:
733 1. Sets the parameters for the file transfer and then starts it. This
734 is done by setting certain (many) global variables, such as the
735 protocol machine start state, the file specification, file type,
736 communication parameters, packet length, window size, character
738 2. Displays messages on the user's screen during the file transfer,
739 using the screen() function, which is called by the group-1
741 3. Executes any commands directly that do not require Kermit protocol,
742 such as the CONNECT command, local file management commands,
743 parameter-setting commands, FTP client commands, etc.
745 If you plan to imbed the [87]Group B, files into a program with a
746 different user interface, your interface must supply an appropriate
747 screen() function, plus a couple related ones like chkint() and
748 intmsg() for handling keyboard (or mouse, etc) interruptions during
749 file transfer. The best way to find out about this is to link all the
750 C-Kermit modules together except the ckuu*.o and ckucon.o modules, and
751 see which missing symbols turn up.
753 C-Kermit's character-oriented user interface (as opposed to the
754 Macintosh version's graphical user interface) consists of the following
755 modules. C-Kermit can be built with an interactive command parser, a
756 command-line-option-only parser, a graphical user interface, or any
757 combination, and it can even be built with no user interface at all (in
758 which case it runs as a remote-mode Kermit server).
762 The command parsing primitives used by the interactive command
763 parser to parse keywords, numbers, filenames, etc, and to give
764 help, complete fields, supply defaults, allow abbreviations and
765 editing, etc. This package is totally independent of Kermit, but
766 does depend on the [90]Group E functions.
769 Definitions of symbols used in Kermit's commands.
772 Kermit's interactive command parser, including the script
773 programming language: [92]ckuusr.c (includes top-level keyword
774 tables); [93]ckuus2.c (HELP command text); [94]ckuus3.c (most of
775 the SET command); [95]ckuus4.c (includes variables and
776 functions); ckuus[567].c (miscellaneous);
779 The command-line-option parser.
782 User interface functions common to both the interactive and
783 command-line parsers.
786 Version heralds for different implementations.
789 The (old, uucp-like) SCRIPT command
792 The DIAL command. Includes specific knowledge of many types of
795 Note that none of the above files is actually Unix-specific. Over time
796 they have proven to be portable among all platforms where C-Kermit is
797 built: Unix, VMS, AOS/VS, Amiga, OS-9, VOS, etc etc. Thus the third
798 letter should more properly be "c", but changing it would be too
802 The CONNECT command. Terminal connection, and in some cases
803 (Macintosh, Windows) also terminal emulation. NOTE: As of
804 C-Kermit 7.0, there are two different CONNECT modules for UNIX:
805 [101]ckucon.c -- the traditional, portable, fork()-based version
806 -- and [102]ckucns.c, a new version that uses select() rather
807 than forks so it can handle encryption. ckucns.c is the
808 preferred version for Unix; ckucon.c is not likely to keep pace
809 with it in terms of upgrades, etc. However, since select() is
810 not portable to every platform, ckucon.c will be kept
811 indefinitely for those platforms that can't use ckucns.c. NOTE:
812 SunLink X.25 support is available only in ckucon.c.
815 Modules having to do with authentication and encryption. Since
816 the relaxation of USA export laws, they are included with the
817 general source-code distribution. Secure C-Kermit binaries can
818 be built using special targets in the standard makefile.
819 However, secure prebuilt binaries may not be distributed.
821 For other implementations, the files may, and probably do, have
822 different names. For example, the Macintosh graphical user interface
823 filenames start with "ckm". Kermit 95 uses the ckucmd and ckuus*
824 modules, but has its own CONNECT command modules. And so on.
826 Here is a brief description of C-Kermit's "user interface interface",
827 from ckuusr.c. It is nowhere near complete; in particular, hundreds of
828 global variables are shared among the many modules. These should, some
829 day, be collected into classes or structures that can be passed around
830 as needed; not only for purity's sake, but also to allow for multiple
831 simultaneous communication sessions and or user interfaces. Our list of
832 things to do is endless, and reorganizing the source is almost always
835 The ckuus*.c modules (like many of the ckc*.c modules) depend on the
836 existence of C library features like fopen, fgets, feof, (f)printf,
837 argv/argc, etc. Other functions that are likely to vary among operating
838 systems -- like setting terminal modes or interrupts -- are invoked via
839 calls to functions that are defined in the [103]Group E
840 platform-dependent modules, ck?[ft]io.c. The command line parser
841 processes any arguments found on the command line, as passed to main()
842 via argv/argc. The interactive parser uses the facilities of the cmd
843 package (developed for this program, but, in theory, usable by any
844 program). Any command parser may be substituted for this one. The only
845 requirements for the Kermit command parser are these:
847 1. Set parameters via global variables like duplex, speed, ttname,
848 etc. See [104]ckcmai.c for the declarations and descriptions of
850 2. If a command can be executed without the use of Kermit protocol,
851 then execute the command directly and set the sstate (start state)
852 variable to 0. Examples include SET commands, local directory
853 listings, the CONNECT command.
854 3. If a command requires the Kermit protocol, set the following
857 'x' (enter server mode) (none)
858 'r' (send a 'get' command) cmarg, cmarg2
859 'v' (enter receive mode) cmarg2
860 'g' (send a generic command) cmarg
861 's' (send files) nfils, cmarg & cmarg2 OR cmlist
862 'c' (send a remote host command) cmarg
865 cmlist is an array of pointers to strings.
866 cmarg, cmarg2 are pointers to strings.
867 nfils is an integer (hmmm, probably should be an unsigned long).
870 A filename string (possibly wild), or:
871 a pointer to a prefabricated generic command string, or:
872 a pointer to a host command string.
875 The name to send a single file under, or:
876 the name under which to store an incoming file; must not
878 If it's the name for receiving, a null value means to
879 store the file under the name it arrives with.
882 A list of nonwild filenames, such as passed via argv.
884 nfils is an integer, interpreted as follows:
885 -1: filespec (possibly wild) in cmarg, must be expanded
887 0: send from stdin (standard input).
888 >0: number of files to send, from cmlist.
890 The screen() function is used to update the screen during file
891 transfer. The tlog() function writes to a transaction log (if TLOG is
892 defined). The debug() function writes to a debugging log (if DEBUG is
893 defined). The intmsg() and chkint() functions provide the user i/o for
894 interrupting file transfers.
896 [ [105]Contents ] [ [106]C-Kermit ] [ [107]Kermit Home ]
898 4.E. Group E: Platform-Dependent I/O
900 Platform-dependent function definitions. All the Kermit modules,
901 including the command package, call upon these functions, which are
902 designed to provide system-independent primitives for controlling and
903 manipulating devices and files. For Unix, these functions are defined
904 in the files [108]ckufio.c (files), [109]ckutio.c (communications), and
905 [110]ckusig.c (signal handling).
907 For VMS, the files are [111]ckvfio.c, ckvtio.c, and [112]ckusig.c (VMS
908 can use the same signal handling routines as Unix). It doesn't really
909 matter what the files are called, except for Kermit distribution
910 purposes (grouping related files together alphabetically), only that
911 each function is provided with the name indicated, observes the same
912 calling and return conventions, and has the same type.
914 The Group E modules contain both functions and global variables that
915 are accessed by modules in the other groups. These are now described.
917 (By the way, I got this list by linking all the C-Kermit modules
918 together except ckutio and ckufio. These are the symbols that ld
919 reported as undefined. But that was a long time ago, probably circa
922 4.E.1. Global Variables
925 Pointer to string containing command for deleting files.
926 Example: char *DELCMD = "rm -f "; (UNIX)
927 Example: char *DELCMD = "delete "; (VMS)
928 Note trailing space. Filename is concatenated to end of this
929 string. NOTE: DELCMD is used only in versions that do not
930 provide their own built-in DELETE command.
933 Pointer to string containing command for listing files when a
935 Example: char *DIRCMD = "/bin/ls -l "; (UNIX)
936 Example: char *DIRCMD = "directory "; (VMS)
937 Note trailing space. Filename is concatenated to end of this
938 string. NOTE: DIRCMD is used only in versions that do not
939 provide their own built-in DIRECTORY command.
942 Pointer to string containing command for listing files when a
943 filespec is not given. (currently not used, handled in another
945 Example: char *DIRCMD2 = "/bin/ls -ld *";
946 NOTE: DIRCMD2 is used only in versions that do not provide their
947 own built-in DIRECTORY command.
950 Pointer to string containing command to display current
952 Example: char *PWDCMD = "pwd ";
953 NOTE: PWDCMD is used only in versions that do not provide their
954 own built-in PWD command.
957 Pointer to command to display free disk space in current
959 Example: char *SPACMD = "df .";
960 NOTE: SPACMD is used only in versions that do not provide their
961 own built-in SPACE command.
964 Pointer to command to display free disk space in another
966 Example: char *SPACM2 = "df ";
967 Note trailing space. Device or directory name is added to this
968 string. NOTE: SPACMD2 is used only in versions that do not
969 provide their own built-in SPACE command.
972 Pointer to command for displaying the contents of a file.
973 Example: char *TYPCMD = "cat ";
974 Note trailing space. Device or directory name is added to this
975 string. NOTE: TYPCMD is used only in versions that do not
976 provide their own built-in TYPE command.
979 Pointer to command for displaying logged-in users.
980 Example: char *WHOCMD = "who ";
981 Note trailing space. Specific user name may be added to this
985 Flag for whether program is running in foreground (0) or
986 background (nonzero). Background operation implies that screen
987 output should not be done and that all errors should be fatal.
990 Flag for who is to echo console typein:
991 1: The program (system is not echoing).
992 0: The OS, front end, terminal, etc (not this program).
995 Pointer to string that names the computer and operating system.
996 Example: char *ckxsys = " NeXT Mach 1.0";
997 Tells what computer system ckxv applies to. In UNIX Kermit, this
998 variable is also used to print the program herald, and in the
999 SHOW VERSION command.
1002 Pointer to version/edit info of ck?tio.c module.
1003 Example: char *ckxv = "UNIX Communications Support, 6.0.169, 6
1005 Used by SHOW VERSION command.
1008 Like ckxsys, but briefer.
1009 Example: char *ckzsys = " 4.3 BSD";
1010 Tells what platform ckzv applies to. Used by the SHOW VERSION
1014 Pointer to version/edit info of ck?fio.c module.
1015 Example: char *ckzv = "UNIX File support, 6.0.113, 6 Sep 96";
1016 Used by SHOW VERSION command.
1019 Default flow control. 0 = none, 1 = Xon/Xoff, ... (see FLO_xxx
1020 symbols in ckcdeb.h)
1021 Set by Group E module. Used by [113]ckcmai.c to initialize flow
1025 Default location. 0 = remote, 1 = local. Set by Group E module.
1026 Used by ckcmai.c to initialize local variable. Used in various
1027 places in the user interface.
1030 Default parity. 0 = none, 'e' = even, 'o' = odd, 'm' = mark, 's'
1031 = space. Set by Group E module. Used by ckcmai.c to initialize
1035 Default communication device. Set by Group E module. Used in
1036 many places. This variable should be initialized the the symbol
1037 CTTNAM, which is defined in ckcdeb.h, e.g. as "/dev/tty" for
1038 UNIX, "TT:" for VMS, etc. Example: char *dftty = CTTNAM;
1041 Array of string pointers to filenames that matched the most
1042 recent wildcard match, i.e. the most recent call to zxpand().
1043 Used (at least) by command parsing package for partial filename
1047 Flag for whether to attempt to expand leading tildes in
1048 directory names (used in UNIX only, and then only when the
1049 symbol DTILDE is defined.
1052 The protocol being used to communicate over a network device.
1053 Values are defined in ckcnet.h. Example: NP_TELNET is network
1057 The maximum length for a filename, exclusive of any device or
1058 directory information, in the format of the host operating
1062 The maximum length for a fully specified filename, including
1063 device designator, directory name, network node name, etc, in
1064 the format of the host operating system, and including all
1068 File descriptor of the communication device. -1 if there is no
1069 open or usable connection, including when C-Kermit is in remote
1070 mode. Since this is not implemented everywhere, references to it
1071 are in #ifdef CK_TTYFD..#endif.
1073 [ [114]Contents ] [ [115]C-Kermit ] [ [116]Kermit Home ]
1077 These are divided into three categories: file-related functions (B.1),
1078 communication functions (B.2), and miscellaneous functions (B.3).
1080 4.E.2.1. File-Related Functions
1082 In most implementations, these are collected together into a module
1083 called ck?fio.c, where ? = "u" ([117]ckutio.c for Unix), "v"
1084 ([118]ckvtio.c for VMS), [119]etc. To be totally platform-independent,
1085 C-Kermit maintains its own file numbers, and provides the functions
1086 described in this section to deal with the files associated with them.
1087 The file numbers are referred to symbolically, and are defined as
1088 follows in ckcker.h:
1090 #define ZCTERM 0 /* Console terminal */
1091 #define ZSTDIO 1 /* Standard input/output */
1092 #define ZIFILE 2 /* Current input file for SEND command */
1093 #define ZOFILE 3 /* Current output file for RECEIVE command */
1094 #define ZDFILE 4 /* Current debugging log file */
1095 #define ZTFILE 5 /* Current transaction log file */
1096 #define ZPFILE 6 /* Current packet log file */
1097 #define ZSFILE 7 /* Current session log file */
1098 #define ZSYSFN 8 /* Input from a system function (pipe) */
1099 #define ZRFILE 9 /* Local file for READ command */ (NEW)
1100 #define ZWFILE 10 /* Local file for WRITE command */ (NEW)
1101 #define ZMFILE 11 /* Auxilliary file for internal use */ (NEW)
1102 #define ZNFILS 12 /* How many defined file numbers */
1104 In the descriptions below, fn refers to a filename, and n refers to one
1105 of these file numbers. Functions are of type int unless otherwise
1106 noted, and are listed mostly alphabetically.
1110 Checks the file number n. Returns:
1111 -1: File number n is out of range
1112 0: n is in range, but file is not open
1113 1: n in range and file is open
1116 iswild(filspec) char *filespec;
1117 Checks if the file specification is "wild", i.e. contains
1118 metacharacters or other notations intended to match multiple
1124 isdir(string) char *string;
1125 Checks if the string is the name of an existing directory. The
1126 idea is to check whether the string can be "cd'd" to, so in some
1127 cases (e.g. DOS) it might also indicate any file structured
1128 device, such as a disk drive (like A:). Other nonzero returns
1129 indicate system-dependent information; e.g. in VMS
1130 isdir("[.FOO]") returns 1 but isdir("FOO.DIR;1") returns 2 to
1131 indicate the directory-file name is in a format that needs
1132 conversion before it can be combined with a filename. Returns:
1133 0: not a directory (including any kind of error)
1134 1: it is an existing directory
1137 zfcdat(name) char *name;
1138 Returns modification (preferably, otherwise creation) date/time
1139 of file whose name is given in the argument string. Return value
1140 is a pointer to a string of the form yyyymmdd hh:mm:ss, for
1141 example 19931231 23:59:59, which represents the local time (no
1142 timezone or daylight savings time finagling required). Returns
1143 the null string ("") on failure. The text pointed to by the
1144 string pointer might be in a static buffer, and so should be
1145 copied to a safe place by the caller before any subsequent calls
1149 zfnqfp(fn, buflen, buf) char * fn; int buflen; char * buf;
1150 Given the filename fn, the corresponding fully qualified,
1151 absolute filename is placed into the buffer buf, whose length is
1152 buflen. On failure returns a NULL pointer. On success returns a
1153 pointer to a struct zfnfp containing pointers to the full
1154 pathname and to just the filename, and an int giving the length
1155 of the full pathname. All references to this function in
1156 mainline code must be protected by #ifdef ZFNQFP..#endif,
1157 because it is not present in all of the ck*fio.c modules. So if
1158 you implement this function in a version that did not have it
1159 before, be sure to add #define ZFNQFP in the appropriate spot in
1160 ckcdeb.h or in the build-procedure CFLAGS.
1163 zcmpfn(s1,s2) char * s2, * s2;
1164 Compares two filenames to see if they refer to the same.
1165 Internally, the arguments can be converted to fully qualified
1166 pathnames, e.g. with zfnqfp(), realpath(), or somesuch. In Unix
1167 or other systems where symbolic links exist, the link should be
1168 resolved before making the comparison or looking at the inodes.
1170 0: Files are not identical.
1171 1: Files are identical.
1174 zfseek(pos) long pos;
1175 Positions the input pointer on the current input file to the
1176 given position. The pos argument is 0-based, the offset
1177 (distance in bytes) from beginning of the file. Needed for
1178 RESEND, PSEND, and other recovery operations. This function is
1179 not necessarily possible on all systems, e.g. record-oriented
1180 systems. It should only be used on binary files (i.e. files we
1181 are sending in binary mode) and stream-oriented file systems.
1187 zchdir(dirnam) char *dirnam;
1188 Changes current or default directory to the one given in dirnam.
1195 Check to see if file with name fn is a regular, readable,
1196 existing file, suitable for Kermit to send -- not a directory,
1197 not a symbolic link, etc. Returns:
1198 -3: if file exists but is not accessible (e.g. read-protected);
1199 -2: if file exists but is not of a readable type (e.g. a
1201 -1: on error (e.g. file does not exist, or fn is garbage);
1202 >=0: (length of file) if file exists and is readable.
1203 Also see isdir(), zgetfs().
1206 zchkpid(pid) unsigned long pid;
1208 1: If the given process ID (e.g. pid in UNIX) is valid and
1213 zgetfs(fn) char *fn;
1214 Gets the size of the given file, regardless of accessibility.
1215 Used for directory listings. Unlike zchki(), should return the
1216 size of any kind of file, even a directory. zgetfs() also should
1217 serve as a mini "get file info" function that can be used until
1218 we design a better one, by also setting some global variables:
1219 int zgfs_link = 1/0 = file is (not) a symbolic link.
1220 int zgfs_dir = 1/0 = file is (not) a directory.
1221 char linkname[] = if zgfs_link != 0, name of file link points
1224 -1: on error (e.g. file does not exist, or fn is garbage);
1225 >=0: (length of file) if file exists and is readable.
1229 Checks to see if a file of the given name can be created.
1231 -1: if file cannot be created, or on any kind of error.
1232 0: if file can be created.
1235 zchkspa(fn,len) char *f; long len;
1236 Checks to see if there is sufficient space to store the file
1237 named fn, which is len bytes long. If you can't write a function
1238 to do this, then just make a dummy that always returns 1; higher
1239 level code will recover from disk-full errors. The receiving
1240 Kermit uses this function to refuse an incoming file based on
1241 its size, via the attribute mechanism. Returns:
1243 0: if there is not enough space.
1244 1: if there is enough space.
1247 zchin(n,c) int n; int *c;
1248 Gets a character from file number n, return it in c (call with
1250 -1: on failure, including EOF.
1251 0: on success with character in c.
1254 zchout(n,c) int n; char c;
1255 Writes the character c to file number n. Returns:
1261 Closes file number n. Returns:
1266 zdelet(fn) char *name;
1267 Attempts to delete (remove, erase) the named file. Returns:
1269 1: if file was deleted successfully.
1273 Returns a pointer to the system-dependent numeric
1274 permissions/protection string for file f, or NULL upon failure.
1275 Used if CK_PERMS is defined.
1279 Returns a pointer to the system-dependent symbolic
1280 permissions/protection string for file f, or NULL upon failure.
1281 Used if CK_PERMS is defined. Example: In UNIX zgperm(f) might
1282 return "100770", but ziperm() might return "-rwxrwx---". In VMS,
1283 zgperm() would return a hexadecimal string, but ziperm() would
1284 return something like "(RWED,RWED,RE,)".
1288 Returns a pointer to the name of the current directory, folder,
1289 etc, or a NULL pointer if the current directory cannot be
1290 determined. If possible, the directory specification should be
1291 (a) fully specified, e.g. as a complete pathname, and (b) be
1292 suitable for appending a filename. Thus, for example, Unix
1293 directory names should end with '/'. VMS directory names should
1294 look like DEV:[NAME] (rather than, say, NAME.DIR;1).
1298 Returns a pointer to a string containing the user's home
1299 directory, or NULL upon error. Should be formatted like zgtdir()
1304 Fill buffer from input file. This function is used by the macro
1305 zminchar(), which is defined in ckcker.h. zminchar() manages its
1306 own buffer, and calls zinfill() to fill it whenever it becomes
1307 empty. It is used only for sending files, and reads characters
1308 only from file number ZIFILE. zinfill() returns -1 upon end of
1309 file, -2 upon fatal error, and -3 upon timeout (e.g. when
1310 reading from a pipe); otherwise it returns the first character
1311 from the buffer it just read.
1315 Kills the current job, session, process, etc, logs out,
1316 disappears. Used by the Kermit server when it receives a BYE
1317 command. On failure, returns -1. On success, does not return at
1318 all! This function should not be called until all other steps
1319 have been taken to close files, etc.
1322 zstrip(fn,&fn2) char *fn1, **fn2;
1323 Strips device and directory, etc, from file specification fn,
1324 leaving only the filename (including "extension" or "filetype"
1325 -- the part after the dot). For example DUA0:[PROGRAMS]OOFA.C;3
1326 becomes OOFA.C, or /usr/fdc/oofa.c becomes oofa.c. Returns a
1327 pointer to result in fn2.
1330 zsetperm(char * file, unsigned int code)
1331 Set permissions of file to given system-dependent code. 0: On
1336 zsetroot(char * dir)
1337 Sets the root for the user's file access, like Unix chroot(),
1338 but does not require privilege. In Unix, this must be
1339 implemented entirely by Kermit's own file access routines.
1342 -1: Invalid argument
1345 -4: Access to given directory denied
1346 -5: New root not within old root
1349 zinroot(char * file)
1350 If no root is set (zsetroot()), returns 1.
1351 Otherwise, if given file is in the root, returns 1.
1352 Otherwise, returns 0.
1355 zltor(fn,fn2) char *fn1, *fn2;
1356 Local-To-Remote filename translation. OBSOLETE: replaced by
1357 nzltor() (q.v.). Translates the local filename fn into a format
1358 suitable for transmission to an arbitrary type of computer, and
1359 copies the result into the buffer pointed to by fn2. Translation
1360 may involve (a) stripping the device and/or directory/path name,
1361 (b) converting lowercase to uppercase, (c) removing spaces and
1362 strange characters, or converting them to some innocuous
1363 alphabetic character like X, (d) discarding or converting extra
1364 periods (there should not be more than one). Does its best.
1365 Returns no value. name2 is a pointer to a buffer, furnished by
1366 the caller, into which zltor() writes the resulting name. No
1367 length checking is done.
1371 nzltor(fn,fn2,convert,pathnames,max) char *fn1,*fn2; int
1372 convert,pathnames,max;
1373 Replaces zltor(). This new version handles pathnames and checks
1374 length. fn1 and fn2 are as in zltor(). This version is called
1375 unconditionally for each file, rather than only when filename
1376 conversion is enabled. Pathnames can have the following values:
1378 PATH_OFF: Pathname, if any, is to be stripped
1379 PATH_REL: The relative pathname is to be included
1380 PATH_ABS: The full pathname is to be included
1382 After handling pathnames, conversion is done to the result as in
1383 the zltor() description if convert != 0; if relative or absolute
1384 pathnames are included, they are converted to UNIX format, i.e.
1385 with slash (/) as the directory separator. The max parameter
1386 specifies the maximum size of fn2. If convert > 0, the regular
1387 conversions are done; if convert < 0, minimal conversions are
1388 done (we skip uppercasing the letters, we allow more than one
1389 period, etc; this can be used when we know our partner is UNIX
1395 nzxpand(fn,flags) char *fn; int flags;
1396 Replaces zxpand(), which is obsolete as of C-Kermit 7.0.
1398 fn = Pointer to filename or pattern.
1399 flags = option bits:
1400 flags & ZX_FILONLY Match regular files
1401 flags & ZX_DIRONLY Match directories
1402 flags & ZX_RECURSE Descend through directory tree
1403 flags & ZX_MATCHDOT Match "dot files"
1404 flags & ZX_NOBACKUP Don't match "backup files"
1405 flags & ZX_NOLINKS Don't follow symlinks.
1407 Returns the number of files that match fn, with data structures
1408 set up so the first file (if any) will be returned by the next
1409 znext() call. If ZX_FILONLY and ZX_DIRONLY are both set, or
1410 neither one is set, files and directories are matched. Notes:
1412 1. It is essential that the number returned by nzxpand() reflect
1413 the actual number of filenames that will be returned by
1414 znext() calls. In other words:
1415 for (n = nzxpand(string,flags); n > 0; n--) {
1417 printf("%s\n", buf);
1420 should print all the file names; no more, no less.
1421 2. In UNIX, DOS, OS-9, etc, where directories contain entries for
1422 themselves (.) and the superior directory (..), these should
1423 NOT be included in the list under any circumstances, including
1424 when ZX_MATCHDOT is set.
1425 3. Additional option bits might be added in the future, e.g. for
1426 sorting (sort by date/name/size, reverse/ascending, etc).
1427 Currently this is done only in higher level code (through a
1428 hack in which the nzxpand() exports its filename array, which
1429 is not portable because not all OS's can use this mechanism).
1432 zmail(addr,fn) char *addr, fn;
1433 Send the local, existing file fn as e-mail to the address addr.
1436 2: if mail delivered but temp file can't be deleted
1437 -2: if mail can't be delivered
1440 zmkdir(path) char *path;
1441 The path can be a file specification that might contain
1442 directory information, in which the filename is expected to be
1443 included, or an unambiguous directory specification (e.g. in
1444 UNIX it must end with "/"). This routine attempts to create any
1445 directories in the given path that don't already exist. Returns
1446 0 or greater success: no directories needed creation, or else
1447 all directories that needed creation were created successfully;
1448 the return code is the number of directories that were created.
1449 Returns -1 on failure to create any of the needed directories.
1452 zrmdir(path) char *path;
1453 Attempts to remove the given directory. Returns 0 on success, -1
1454 on failure. The detailed semantics are open -- should it fail if
1455 the directory contains any files or subdirectories, etc. It is
1456 probably best for this routine to behave in whatever manner is
1457 customary on the underlying platform; e.g. in UNIX, VMS, DOS,
1458 etc, where directories can not be removed unless they are empty.
1461 znewn(fn,s) char *fn, **s;
1462 Transforms the name fn into a filename that is guaranteed to be
1463 unique. If the file fn does not exist, then the new name is the
1464 same as fn; Otherwise, it's different. this function does its
1465 best, returns no value. New name is created in caller's space.
1466 Call like this: znewn(old,&new);. The second parameter is a
1467 pointer to the new name. This pointer is set by znewn() to point
1468 to a static string in its own space, so be sure to the result to
1469 a safe place before calling this function again.
1473 Copies the next file name from a file list created by zxpand()
1474 into the string pointed to by fn (see zxpand). If no more files,
1475 then the null string is placed there. Returns 0 if there are no
1476 more filenames, with 0th element the array pointed to by fn set
1477 to NUL. If there is a filename, it is stored in the array
1478 pointed to by fn and a positive number is returned. NOTE: This
1479 is a change from earlier definitions of this function
1480 (pre-1999), which returned the number of files remaining; thus 0
1481 was the return value when returning the final file. However, no
1482 mainline code ever depended on the return value, so this change
1486 zopeni(n,fn) int n; char *fn;
1487 Opens the file named fn for input as file number n. Returns:
1492 zopeno(n,fn,zz,fcb) int n; char *name; struct zattr *zz; struct
1494 Attempts to open the named file for output as file number n. zz
1495 is a Kermit file attribute structure as defined in ckcdeb.h,
1496 containing various information about the file, including its
1497 size, creation date, and so forth. This function should attempt
1498 to honor as many of these as possible. fcb is a "file control
1499 block" in the traditional sense, defined in ckcdeb.h, containing
1500 information relevant to complicated file systems like VMS (RMS),
1501 IBM MVS, etc, like blocksize, record length, organization,
1502 record format, carriage control, etc. Returns:
1508 Dumps a file output buffer. Used with the macro zmchout()
1509 defined in ckcker.h. Used only with file number ZOFILE, i.e. the
1510 file that is being received by Kermit during file transfer.
1516 zprint(p,fn) char *p, *f;
1517 Prints the file with name fn on a local printer, with options p.
1520 3: if file sent to printer but can't be deleted
1521 -3: if file can't be printed
1524 zrename(fn,fn2) char *fn, *fn2;
1525 Changes the name of file fn to fn2. If fn2 is the name of an
1526 existing directory, or a file-structured device, then file fn is
1527 moved to that directory or device, keeping its original name. If
1528 fn2 lacks a directory separator when passed to this function, an
1529 appropriate one is supplied. Returns:
1534 zcopy(source,dest) char * source, * dest;
1535 Copies the source file to the destination. One file only. No
1536 wildcards. The destination string may be a filename or a
1537 directory name. Returns:
1540 -2: source file is not a regular file.
1541 -3: source file not found.
1542 -4: permission denied.
1543 -5: source and destination are the same file.
1549 Call with: "yyyymmdd hh:mm:ss" GMT/UTC date-time. Returns
1550 pointer to local date-time string "yyyymmdd hh:mm:ss" on
1551 success, NULL on failure.
1554 zrtol(fn,fn2) char *fn, *fn2;
1555 Remote-To-Local filename translation. OBSOLETE: replaced by
1556 nzrtol(). Translates a "standard" filename to a local filename.
1557 For example, in Unix this function might convert an
1558 all-uppercase name to lowercase, but leave lower- or mix-case
1559 names alone. Does its best, returns no value. New name is in
1560 string pointed to by fn2. No length checking is done.
1564 nzrtol(fn,fn2,convert,pathnames,max) char *fn1,*fn2; int
1565 convert,pathnames,max;
1566 Replaces zrtol. Like zrtol but handles pathnames and checks
1567 length. See nzltor for detailed description of parameters.
1572 zsattr(xx) struct zattr *xx;
1573 Fills in a Kermit file attribute structure for the file which is
1574 to be sent, namely the currently open ZIFILE. Note that this is
1575 not a very good design, but we're stuck with it. Callers must
1576 ensure that zsattr() is called only on real files, not on pipes,
1577 internally generated file-like objects such as server REMOTE
1578 command responses, etc. Returns:
1580 0: on success with the structure filled in.
1581 If any string member is null, it should be ignored by the
1583 If any numeric member is -1, it should be ignored by the caller.
1587 s contains to pointer to a command to be executed by the host
1588 computer's shell, command parser, or operating system. If the
1589 system allows the user to choose from a variety of command
1590 processors (shells), then this function should employ the user's
1591 preferred shell. If possible, the user's job (environment,
1592 process, etc) should be set up to catch keyboard interruption
1593 signals to allow the user to halt the system command and return
1594 to Kermit. The command must run in ordinary, unprivileged user
1595 mode. If possible, this function should return -1 on failure to
1596 start the command, or else it should return 1 if the command
1597 succeeded and 0 if it failed.
1601 zshcmd() and zsyscmd() should set this to the command's actual
1602 exit status code if possible.
1606 s contains to pointer to a command to be executed by the host
1607 computer's shell, command parser, or operating system. If the
1608 system allows the user to choose from a variety of command
1609 processors (shells), then this function should employ the system
1610 standard shell (e.g. /bin/sh for Unix), so that the results will
1611 always be the same for everybody. If possible, the user's job
1612 (environment, process, etc) should be set up to catch keyboard
1613 interruption signals to allow the user to halt the system
1614 command and return to Kermit. The command must run in ordinary,
1615 unprivileged user mode. If possible, this function should return
1616 -1 on failure to start the command, or else it should return 1
1617 if the command succeeded and 0 if it failed.
1620 z_exec(s,args) char * s; char * args[];
1621 This one executes the command s (which is searched for using the
1622 system's normal searching mechanism, such as PATH in UNIX), with
1623 the given argument vector, which follows the conventions of UNIX
1624 argv[]: the name of the command pointed to by element 0, the
1625 first arg by element 1, and so on. A null args[] pointer
1626 indicates the end of the arugment list. All open files must
1627 remain open so the exec'd process can use them. Returns only if
1631 zsinl(n,s,x) int n, x; char *s;
1632 Reads a line from file number n. Writes the line into the
1633 address s provided by the caller. Writing terminates when
1634 newline is read, but with newline discarded. Writing also
1635 terminates upon EOF or if length x is exhausted. Returns:
1636 -1: on EOF or error.
1640 zsout(n,s) int n; char *s;
1641 Writes the string s out to file number n. Returns:
1646 zsoutl(n,s) int n; char *s;
1647 Writes the string s out to file number n and adds a line
1648 (record) terminator (boundary) appropriate for the system and
1649 the file format. Returns:
1654 zsoutx(n,s,x) int n, x; char *s;
1655 Writes exactly x characters from string s to file number n. If s
1656 has fewer than x characters, then the entire string s is
1659 >= 0: on success, the number of characters actually written.
1662 zstime(fn,yy,x) char *fn; struct zattr *yy; int x;
1663 Sets the creation date (and other attributes) of an existing
1664 file, or compares a file's creation date with a given date. Call
1667 fn: pointer to name of existing file.
1668 yy: Pointer to a Kermit file attribute structure in which yy->date.val
1669 is a date of the form yyyymmdd hh:mm:ss, e.g. 19900208 13:00:00, which
1670 is to be used for setting or comparing the file date. Other attributes
1671 in the struct can also be set, such as the protection/permission (See
1672 [120]Appendix I), when it makes sense (e.g. "yy->lprotect.val" can be
1673 set if the remote system ID matches the local one).
1674 x: A function code: 0 means to set the file's creation date as given.
1675 1 means compare the date from the yy struct with the file's date.
1678 -1: on any kind of error.
1679 0: if x is 0 and the file date was set successfully.
1680 0: if x is 1 and date from attribute structure > file creation
1682 1: if x is 1 and date from attribute structure <= file
1686 zstrip(name,name2) char *name, **name2;
1687 Strips pathname from filename "name". Constructs the resulting
1688 string in a static buffer in its own space and returns a pointer
1689 to it in name2. Also strips device name, file version numbers,
1690 and other "non-name" material.
1694 Runs a system command so its output can be accessed as if it
1695 were file n. The command is run in ordinary, unprivileged user
1697 If n is ZSTDIO or ZCTERM, returns -1.
1698 If n is ZIFILE or ZRFILE, then Kermit reads from the command,
1699 otherwise Kermit writes to the command.
1700 Returns 0 on error, 1 on success.
1703 zxpand(fn) char *fn;
1704 OBSOLETE: Replaced by nzxpand(), q.v.
1709 Returns the number of files returned by the most recent
1710 nzxpand() call, and resets the list to the beginning so the next
1711 znext() call returns the first file. Returns -1 if zxpand has
1712 not yet been called. If this function is available, ZXREWIND
1713 should be defined; otherwise it should not be referenced.
1715 #endif /* ZXREWIND */
1718 xsystem(cmd) char *cmd;
1719 Executes the system command without redirecting any of its i/o,
1720 similar (well, identical) to system() in Unix. But before
1721 passing the command to the system, xsystem() ensures that all
1722 privileges are turned off, so that the system command executes
1723 in ordinary unprivileged user mode. If possible, xsystem()
1724 returns the return code of the command that was executed.
1726 4.E.2.2. IKSD Variables and Functions
1728 These must be implemented in any C-Kermit version that is to be
1729 installed as an Internet Kermit Service Daemon (IKSD). IKSD is expected
1730 to be started by the Internet Daemon (e.g. inetd) with its standard i/o
1731 redirected to the incoming connection.
1734 Nonzero if anonymous logins allowed.
1736 extern int inserver;
1737 Nonzero if started in IKSD mode.
1740 Nonzero if IKSD and user logged in anonymously.
1742 extern char * homdir;
1743 Pointer to user's home directory.
1745 extern char * anonroot;
1746 Pointer to file-system root for anonymous users.
1748 Existing functions must make "if (inserver && isguest)" checks for
1749 actions that would not be legal for guests: zdelete(), zrmdir(),
1750 zprint(), zmail(), etc.
1753 zvuser(name) char * name;
1754 Verifies that user "name" exists and is allowed to log in. If
1755 the name is "ftp" or "anonymous" and ckxanon != 0, a guest login
1756 is set up. Returns 0 if user not allowed to log in, nonzero if
1760 zvpass(string) char * string;
1761 Verifies password of the user from the most recent zvuser()
1762 call. Returns nonzero if password is valid for user, 0 if it
1763 isn't. Makes any appropriate system log entries (IKSD logins,
1764 failed login attempts, etc). If password is valid, logs the user
1765 in as herself (if real user), or sets up restricted anonymous
1766 access if user is guest (e.g. changes file-system root to
1767 anonroot and sets isguest = 1).
1771 Begins any desired system logging of an IKSD session.
1775 Terminates an IKSD session. In most cases this is simply a
1776 wrapper for exit() or doexit(), with some system logging added.
1778 4.E.2.3. Privilege Functions
1780 These functions are used by C-Kermit to adapt itself to operating
1781 systems where the program can be made to run in a "privileged" mode,
1782 e.g. setuid or setgid in Unix. C-Kermit should NOT read and write files
1783 or start subprocesses as a privileged program. This would present a
1784 serious threat to system security. The security package has been
1785 installed to prevent such security breaches by turning off the
1786 program's special privileges at all times except when they are needed.
1788 In UNIX, the only need Kermit has for privileged status is access to
1789 the UUCP lockfile directory, in order to read, create, and destroy
1790 lockfiles, and to open communication devices that are normally
1791 protected against the user (see the [121]Unix C-Kermit Installation
1792 Instructions for discussion). Therefore, privileges should only be
1793 enabled for these operations and disabled at all other times. This
1794 relieves the programmer of the responsibility of putting expensive and
1795 unreliable access checks around every file access and subprocess
1798 Strictly speaking, these functions are not required in all C-Kermit
1799 implementations, because their use (so far, at least) is internal to
1800 the Group E modules. However, they should be included in all C-Kermit
1801 implementations for operating systems that support the notion of a
1802 privileged program (UNIX, RSTS/E, what others?).
1806 Determine whether the program is running in privileged status.
1807 If so, turn off the privileges, in such a way that they can be
1808 turned on again when needed. Called from sysinit() at program
1809 startup time. Returns:
1811 nonzero on failure, in which case the program should halt
1816 If the program is not privileged, this function does nothing. If
1817 the program is privileged, this function returns it to
1818 privileged status. priv_ini() must have been called first.
1825 Turns privileges off (if they are on) in such a way that they
1826 can be turned back on again. Returns:
1832 Turns privileges off in such a way that they cannot be turned
1839 Attempts to turns privileges off in such a way that they can be
1840 turned on again later. Then checks to make sure that they were
1841 really turned off. If they were not really turned off, then they
1842 are cancelled permanently. Returns:
1846 4.E.2.4. Console-Related Functions
1848 These relate to the program's "console", or controlling terminal, i.e.
1849 the terminal that the user is logged in on and types commands at, or on
1850 a PC or workstation, the actual keyboard and screen.
1853 conbin(esc) char esc;
1854 Puts the console into "binary" mode, so that Kermit's command
1855 parser can control echoing and other treatment of characters
1856 that the user types. esc is the character that will be used to
1857 get Kermit's attention during packet mode; puts this in a global
1858 place. Sets the ckxech variable. Returns:
1863 concb(esc) char esc;
1864 Put console in "cbreak" (single-character wakeup) mode. That is,
1865 ensure that each console character is available to the program
1866 immediately when the user types it. Otherwise just like
1873 Returns a number, 0 or greater, the number of characters waiting
1874 to be read from the console, i.e. the number of characters that
1875 the user has typed that have not been read yet by Kermit.
1879 Returns the speed ("baud rate") of the controlling terminal, if
1880 known, otherwise -1L.
1883 congks(timo) int timo;
1884 Get Keyboard Scancode. Reads a keyboard scan code from the
1885 physical console keyboard. If the timo parameter is greater than
1886 zero, then times out and returns -2 if no character appears
1887 within the given number of seconds. Upon any other kind of
1888 error, returns -1. Upon success returns a scan code, which may
1889 be any positive integer. For situations where scan codes cannot
1890 be read (for example, when an ASCII terminal is used as the
1891 job's controlling terminal), this function is identical to
1892 coninc(), i.e. it returns an 8-bit character value. congks() is
1893 for use with workstations whose keyboards have Alternate,
1894 Command, Option, and similar modifier keys, and Function keys
1895 that generate codes greater than 255.
1899 Console get modes. Gets the current console terminal modes and
1900 saves them so that conres() can restore them later. Returns 1 if
1901 it got the modes OK, 0 if it did nothing (e.g. because Kermit is
1902 not connected with any terminal), -1 on error.
1905 coninc(timo) int timo;
1906 Console Input Character. Reads a character from the console. If
1907 the timo parameter is greater than zero, then coninc() times out
1908 and returns -2 if no character appears within the given number
1909 of seconds. Upon any other kind of error, returns -1. Upon
1910 success, returns the character itself, with a value in the range
1914 conint(f,s) SIGTYP (*f)(), (*s)();
1915 Sets the console to generate an interrupt if the user types a
1916 keyboard interrupt character, and to transfer control the
1917 signal-handling function f. For systems with job control, s is
1918 the address of the function that suspends the job. Sets the
1919 global variable "backgrd" to zero if Kermit is running in the
1920 foreground, and to nonzero if Kermit is running in the
1921 background. See ckcdeb.h for the definition of SIGTYP. No return
1926 Console no interrupts. Disable keyboard interrupts on the
1927 console. No return value.
1931 Writes character c to the console terminal. Returns:
1932 0 on failure, 1 on success.
1936 Writes string s to the console. Returns -1 on error, 0 or
1940 conola(s) char *s[]; {
1941 Writes an array of strings to the console. Returns -1 on error,
1942 0 or greater on success.
1946 Writes string s to the console, followed by the necessary line
1947 termination characters to put the console cursor at the
1948 beginning of the next line. Returns -1 on error, 0 or greater on
1953 Restores the console terminal to the modes obtained by congm().
1954 Returns: -1 on error, 0 on success.
1957 conxo(x,s) int x; char *s;
1958 Write x characters from string s to the console. Returns 0 or
1959 greater on success, -1 on error.
1963 Returns a pointer to the designator of the console keyboard
1964 type. For example, on a PC, this function would return "88",
1965 "101", etc. Upon failure, returns a pointer to the empty string.
1967 4.E.2.5. Communications Functions
1969 The communication device is the device used for terminal emulation and
1970 file transfer. It may or may not be the same device as the console, and
1971 it may or may not be a terminal (serial-port) device; it could also be
1972 a network connection. For brevity, the communication device is referred
1973 to here as the "tty". When the communication device is the same as the
1974 console device, Kermit is said to be in remote mode. When the two
1975 devices are different, Kermit is in local mode.
1979 Returns the number of characters that have arrived at the
1980 communication device but have not yet been read by ttinc(),
1981 ttinl(), and friends. If communication input is buffered (and it
1982 should be), this is the sum of the number of unread characters
1983 in Kermit's buffer PLUS the number of unread characters in the
1984 operating system's internal buffer. The call must be
1985 nondestructive and nonblocking, and as inexpensive as possible.
1987 0: or greater on success,
1988 0: in case of internal error,
1989 -1: or less when it determines the connection has been broken,
1990 or there is no connection.
1992 That is, a negative return from ttchk() should reliably indicate
1993 that there is no usable connection. Furthermore, ttchk() should
1994 be callable at any time to see if the connection is open. When
1995 the connection is open, every effort must be made to ensure that
1996 ttchk returns an accurate number of characters waiting to be
1997 read, rather than just 0 (no characters) or 1 (1 or more
1998 characters), as would be the case when we use select(). This
1999 aspect of ttchk's operation is critical to successful operation
2000 of sliding windows and streaming, but "nondestructive buffer
2001 peeking" is an obscure operating system feature, and so when it
2002 is not available, we have to do it ourselves by managing our own
2003 internal buffer at a level below ttinc(), ttinl(), etc, as in
2004 the UNIX version (non-FIONREAD case).
2006 An external global variable, clsondisc, if nonzero, means that
2007 if a serial connection drops (carrier on-to-off transition
2008 detected by ttchk()), the device should be closed and released
2013 Closes the communication device (tty or network). If there were
2014 any kind of exclusive access locks connected with the tty, these
2015 are released. If the tty has a modem connection, it is hung up.
2016 For true tty devices, the original tty device modes are
2023 Flush communications input buffer. If any characters have
2024 arrived but have not yet been read, discard these characters. If
2025 communications input is buffered by Kermit (and it should be),
2026 this function flushes Kermit's buffer as well as the operating
2027 system's internal input buffer. Returns:
2033 Flush tty output buffer. If any characters have been written but
2034 not actually transmitted (e.g. because the system has been
2035 flow-controlled), remove them from the system's output buffer.
2036 (Note, this function is not actually used, but it is recommended
2037 that all C-Kermit programmers add it for future use, even if it
2038 is only a dummy function that returns 0 always.)
2042 Looks for the modem signals CTS, DSR, and CTS, and returns those
2043 that are on in as its return value, in a bit mask as described
2044 for ttwmdm, in which a bit is on (1) or off (0) according to
2045 whether the corresponding signal is on (asserted) or off (not
2046 asserted). Return values:
2048 -2: if the line does not have modem control
2050 >=0: on success, with bit mask containing the modem signals.
2054 Returns the current tty speed in BITS (not CHARACTERS) per
2055 second, or -1 if it is not known or if the tty is really a
2056 network, or upon any kind of error. On success, the speed
2057 returned is the actual number of bits per second, like 1200,
2062 Get terminal window size. Returns -1 on error, 0 if the window
2063 size can't be obtained, 1 if the window size has been
2064 successfully obtained. Upon success, the external global
2065 variables tt_rows and tt_cols are set to the number of screen
2066 rows and number of screen columns, respectively. As this
2067 function is not implemented in all ck*tio.c modules, calls to it
2068 must be wrapped in #ifdef CK_TTGWSIZ..#endif. NOTE: This
2069 function must be available to use the TELNET NAWS feature
2070 (Negotiate About Window Size) as well as Rlogin.
2074 Hang up the current tty device. For real tty devices, turn off
2075 DTR for about 1/3-1/2 second (or other length of time, depending
2076 on the system). If the tty is really a network connection, close
2079 0: if it does not even try to hang up.
2080 1: if it believes it hung up successfully.
2084 Turns off all pending timer interrupts.
2087 ttinc(timo) int timo; (function is old, return codes are new)
2088 Reads one character from the communication device. If timo is
2089 greater than zero, wait the given number of seconds and then
2090 time out if no character arrives, otherwise wait forever for a
2092 -3: internal error (e.g. tty modes set wrong)
2093 -2: communications disconnect
2094 -1: timeout or other error
2095 >=0: the character that was read.
2096 It is HIGHLY RECOMMENDED that ttinc() be internally buffered so
2097 that calls to it are relatively inexpensive. If it is possible
2098 to to implement ttinc() as a macro, all the better, for example
2101 #define ttinc(t) ( (--txbufn >= 0) ? txbuf[ttbufp++] : txbufr(t) )
2103 (see description of txbufr() below)
2106 ttinl(dest,max,timo,eol,start,turn) int max,timo,turn; CHAR
2108 ttinl() is Kermit's packet reader. Reads a packet from the
2109 communications device, or up to max characters, whichever occurs
2110 first. A line is a string of characters starting with the start
2111 character up to and including the character given in eol or
2112 until the length is exhausted, or, if turn != 0, until the line
2113 turnaround character (turn) is read. If turn is 0, ttinl()
2114 *should* use the packet length field to detect the end, to allow
2115 for the possibility that the eol character appears unprefixed in
2116 the packet data. (The turnaround character is for half-duplex
2117 linemode connections.)
2119 If timo is greater than zero, ttinl() times out if the eol
2120 character is not encountered within the given number of seconds
2123 The characters that were input are copied into "dest" with their
2124 parity bits stripped if parity is not none. The first character
2125 copied into dest should be the start character, and the last
2126 should be the final character of the packet (the last block
2127 check character). ttinl() should also absorb and discard the eol
2128 and turn characters, and any other characters that are waiting
2129 to be read, up until the next start character, so that
2130 subsequent calls to ttchk() will not succeed simply because
2131 there are some terminators still sitting in the buffer that
2132 ttinl() didn't read. This operation, if performed, MUST NOT
2133 BLOCK (so if it can't be performed in a guaranteed nonblocking
2136 On success, ttinl() returns the number of characters read.
2137 Optionally, ttinl() can sense the parity of incoming packets. If
2138 it does this, then it should set the global variable ttprty
2139 accordingly. ttinl() should be coded to be as efficient as
2140 possible, since it is at the "inner loop" of packet reception.
2142 -1: Timeout or other possibly correctable error.
2143 -2: Interrupted from keyboard.
2144 -3: Uncorrectable i/o error -- connection lost, configuration
2146 >=0: on success, the number of characters that were actually
2147 read and placed in the dest buffer, not counting the trailing
2152 Outputs the character c to the communication line. If the
2153 operation fails to complete within two seconds, this function
2154 returns -1. Otherwise it returns the number of characters
2155 actually written to the tty (0 or 1). This function should only
2156 be used for interactive, character-mode operations, like
2157 terminal connection, script execution, dialer i/o, where the
2158 overhead of the signals and alarms does not create a bottleneck.
2159 (THIS DESCRIPTION NEEDS IMPROVEMENT -- If the operation fails
2160 within a "certain amount of time"... which might be dependent on
2161 the communication method, speed, etc. In particular,
2162 flow-control deadlocks must be accounted for and broken out of
2163 to prevent the program from hanging indefinitely, etc.)
2166 ttol(s,n) int n; char *s;
2167 Kermit's packet writer. Writes the n characters of the string
2168 pointed to to by s. NOTE: It is ttol's responsibility to write
2169 ALL of the characters, not just some of them. Returns:
2170 -1: on a possibly correctable error (so it can be retried).
2171 -3: on a fatal error, e.g. connection lost.
2172 >=0: on success, the actual number of characters written (the
2173 specific number is not actually used for anything).
2176 ttopen(ttname,lcl,modem,timo) char *ttname; int *lcl, modem,
2178 Opens a tty device, if it is not already open. ttopen must check
2179 to make sure the SAME device is not already open; if it is,
2180 ttopen returns successfully without doing anything. If a
2181 DIFFERENT device is currently open, ttopen() must call ttclos()
2182 to close it before opening the new one.
2187 character string - device name or network host name.
2190 If called with lcl < 0, sets value of lcl as
2192 0: the terminal named by ttname is the job's
2193 controlling terminal.
2194 1: the terminal named by ttname is not the job's
2195 controlling terminal.
2196 If the device is already open, or if the requested
2197 device can't be opened, then lcl remains (and is
2201 Less than zero: this is the negative of the network
2202 type, and ttname is a network host name. Network
2203 types (from [122]ckcnet.h:
2205 NET_TCPB 1 TCP/IP Berkeley (socket) (implemented in [123]ckutio.c)
2206 NET_TCPA 2 TCP/IP AT&T (streams) (not yet implemented)
2207 NET_DEC 3 DECnet (not yet implemented)
2209 Zero or greater: ttname is a terminal device name.
2210 Zero means a direct connection (don't use modem
2211 signals). Positive means use modem signals depending
2212 on the current setting of ttcarr (see ttscarr()).
2215 > 0: number of seconds to wait for open() to return
2217 <=0: no timer, wait forever (e.g. for incoming
2219 For real tty devices, ttopen() attempts to gain
2220 exclusive access to the tty device, for example in
2221 UNIX by creating a "lockfile" (in other operating
2222 systems, like VMS, exclusive access probably
2223 requires no special action).
2226 Copies its arguments and the tty file descriptor to global
2227 variables that are available to the other tty-related
2228 functions, with the lcl value altered as described above.
2229 Gets all parameters and settings associated with the line
2230 and puts them in a global area, so that they can be
2231 restored by ttres(), e.g. when the device is closed.
2235 -5: if device is in use
2236 -4: if access to device is denied
2237 -3: if access to lock mechanism denied
2238 -2: upon timeout waiting for device to open
2242 ttpkt(speed,flow,parity) long speed; int flow, parity;
2243 Puts the currently open tty device into the appropriate modes
2244 for transmitting and receiving Kermit packets.
2249 if speed > -1, and the device is a true tty device,
2250 and Kermit is in local mode, ttpkt also sets the
2254 if in the range 0-3, ttpkt selects the corresponding
2255 type of flow control. Currently 0 is defined as no
2256 flow control, 1 is Xon/Xoff, and no other types are
2257 defined. If (and this is a horrible hack, but it
2258 goes back many years and will be hard to eradicate)
2259 flow is 4, then the appropriate tty modes are set
2260 for modem dialing, a special case in which we talk
2261 to a modem-controlled line without requiring
2262 carrier. If flow is 5, then we require carrier.
2265 This is simply copied into a global variable so that
2266 other functions (like ttinl, ttinc, etc) can use it.
2269 Copies its arguments to global variables, flushes the
2270 terminal device input buffer.
2278 Enables the given type of flow control on the open serial
2279 communications device immediately. Arguments are the FLO_xxx
2280 values from ckcdeb.h, except FLO_DIAL, FLO_DIAX, or FLO_AUTO,
2281 which are not actual flow-control types. Returns 0 on success,
2287 Returns a pointer to an array of longs, or NULL on failure. On
2288 success, element 0 of the array contains number, n, indicating
2289 how many follow. Elements 1-n are serial speeds, expressed in
2290 bits per second, that are legal on this platform. The user
2291 interface may use this list to construct a menu, keyword table,
2294 #endif /* TTSPDLIST */
2298 Restores the tty device to the modes and settings that were in
2299 effect at the time it was opened (see ttopen). Returns:
2304 ttruncmd(string) char * string;
2305 Runs the given command on the local system, but redirects its
2306 input and output to the communication (SET LINE, SET PORT, or
2307 SET HOST) device. Returns:
2312 ttscarr(carrier) int carrier;
2313 Copies its argument to a variable that is global to the other
2314 tty-related functions, and then returns it. The values for
2315 carrier are defined in ckcdeb.h: CAR_ON, CAR_OFF, CAR_AUTO.
2316 ttopen(), ttpkt(), and ttvt() use this variable when deciding
2317 how to open the tty device and what modes to select. The
2320 CAR_OFF: Ignore carrier at all times.
2321 CAR_ON: Require carrier at all times, except when dialing. This means,
2322 for example, that ttopen() could hang forever waiting for carrier if it
2324 CAR_AUTO: If the modem type is zero (i.e. the connection is direct),
2325 this is the same as CAR_OFF. If the modem type is positive, then heed
2326 carrier during CONNECT (ttvt mode), but ignore it at other times
2327 (packet mode, during SET LINE, etc). Compatible with pre-5A versions of
2328 C-Kermit. This should be the default carrier mode.
2330 Kermit's DIAL command ignores the carrier setting, but ttopen(),
2331 ttvt(), and ttpkt() all honor the carrier option in effect at
2332 the time they are called. None of this applies to remote mode
2333 (the tty device is the job's controlling terminal) or to network
2334 host connections (modem type is negative).
2338 Sends a BREAK signal on the tty device. On a real tty device,
2339 send a real BREAK lasting approximately 275 milliseconds. If
2340 this is not possible, simulate a BREAK by (for example) dropping
2341 down some very low baud rate, like 50, and sending a bunch of
2342 null characters. On a network connection, do the appropriate
2343 network protocol for BREAK. Returns:
2349 Like ttsndb(), but sends a "Long BREAK" (approx 1.5 seconds).
2350 For network connections, it is identical to ttsndb(). Currently,
2351 this function is used only if CK_LBRK is defined (as it is for
2355 ttsspd(cps) int cps;
2356 For serial devices only, set the device transmission speed to
2357 (note carefully) TEN TIMES the argument. The argument is in
2358 characters per second, but transmission speeds are in bits per
2359 second. cps are used rather than bps because high speeds like
2360 38400 are not expressible in a 16-bit int but longs cannot be
2361 used because keyword-table values are ints and not longs. If the
2362 argument is 7, then the bps is 75, not 70. If the argument is
2363 888, this is a special code for 75/1200 split-speed operation
2364 (75 bps out, 1200 bps in). Returns:
2365 -1: on error, meaning the requested speed is not valid or
2367 >=0: on success (don't try to use this value for anything).
2370 ttvt(speed,flow) long speed; int flow;
2371 Puts the currently open tty device into the appropriate modes
2372 for terminal emulation. The arguments are interpreted as in
2373 ttpkt(). Side effects: ttvt() stores its arguments in global
2374 variables, and sets a flag that it has been called so that
2375 subsequent calls can be ignored so long as the arguments are the
2376 same as in the last effective call. Other functions, such as
2377 ttopen(), ttclose(), ttres(), ttvt(), etc, that change the tty
2378 device in any way must unset this flag. In UNIX Kermit, this
2379 flag is called tvtflg.
2382 ttwmdm(mdmsig,timo) int mdmsig, timo;
2383 Waits up to timo seconds for all of the given modem signals to
2384 appear. mdmsig is a bit mask, in which a bit is on (1) or off
2385 (0) according to whether the corresponding signal is to be
2386 waited for. These symbols are defined in ckcdeb.h:
2387 BM_CTS (bit 0) means wait for Clear To Send
2388 BM_DSR (bit 1) means wait for Data Set Ready
2389 BM_DCD (bit 2) means wait for Carrier Detect
2391 -3: Not implemented.
2392 -2: This line does not have modem control.
2393 -1: Timeout: time limit exceeded before all signals were
2398 ttxin(n,buf) int n; CHAR *buf;
2399 Reads x characters from the tty device into the specified buf,
2400 stripping parity if parity is not none. This call waits forever,
2401 there is no timeout. This function is designed to be called only
2402 when you know that at least x characters are waiting to be read
2403 (as determined, for example, by ttchk()). This function should
2404 use the same buffer as ttinc().
2407 txbufr(timo) int timo;
2408 Reads characters into the internal communications input buffer.
2409 timo is a timeout interval, in seconds. 0 means no timeout, wait
2410 forever. Called by ttinc() (and possibly ttxin() and ttinl())
2411 when the communications input buffer is empty. The buffer should
2412 be called ttxbuf[], its length is defined by the symbol TXBUFL.
2413 The global variable txbufn is the number of characters available
2414 to be read from ttxbuf[], and txbufp is the index of the next
2415 character to be read. Should not be called if txbufn > 0, in
2416 which case the buffer does not need refilling. This routine
2418 -2: Communications disconnect
2420 >=0: A character (0 - 255) On success, the first character that
2421 was read, with the variables txbufn and txbufp set appropriately
2422 for any remaining characters.
2423 NOTE: Currently this routine is used internally only by the UNIX
2424 and VMS versions. The aim is to make it available to all
2425 versions so there is one single coherent and efficient way of
2426 reading from the communications device or network.
2428 4.E.2.6. Miscellaneous system-dependent functions
2432 Returns a pointer, s, to the current date-and-time string in s.
2433 This string must be in the fixed-field format associated with
2434 the C runtime asctime() function, like: "Sun Sep 16 13:23:45
2435 1973\n" so that callers of this function can extract the
2436 different fields. The pointer value is filled in by ztime, and
2437 the data it points to is not safe, so should be copied to a safe
2438 place before use. ztime() has no return value. As a side effect,
2439 this routine can also fill in the following two external
2440 variables (which must be defined in the system-dependendent
2441 modules for each platform):
2442 long ztusec: Fraction of seconds of clock time, microseconds.
2443 long ztmsec: Fraction of seconds of clock time, milliseconds.
2444 If these variables are not set by zstime(), they remain at their
2445 initial value of -1L.
2449 Returns the current value of the elapsed time counter in seconds
2450 (see rtimer), or 0 on any kind of error.
2455 Returns the current value of the elapsed time counter in
2456 seconds, as a floating point number, capable of representing not
2457 only whole seconds, but also the fractional part, to the
2458 millisecond or microsecond level, whatever precision is
2459 available. Requires a function to get times at subsecond
2460 precision, as well as floating-point support. That's why it's
2463 #endif /* GFTIMER */
2467 Sleeps (pauses, does nothing) for m milliseconds (a millisecond
2468 is one thousandth of a second). Returns:
2474 Sets the elapsed time counter to zero. If you want to time how
2475 long an operation takes, call rtimer() when it starts and gtimer
2476 when it ends. rtimer() has no return value.
2481 Sets the elapsed time counter to zero. If you want to time how
2482 long an operation takes, call rftimer() when it starts and
2483 gftimer when it ends. rftimer() has no return value. Note:
2484 rftimer() is to be used with gftimer() and rtimer() is to be
2485 used with gtimer(). See the rftimer() description.
2487 #endif /* GFTIMER */
2491 Does whatever needs doing upon program start. In particular, if
2492 the program is running in any kind of privileged mode, turns off
2493 the privileges (see priv_ini()). Returns:
2499 Does whatever needs doing upon program exit. Returns:
2505 Suspends the Kermit process, puts it in the background so it can
2506 be continued ("foregrounded") later. Returns:
2507 -1: if this function is not supported.
2510 [ [124]Contents ] [ [125]C-Kermit ] [ [126]Kermit Home ]
2512 4.F. Group F: Network Support
2514 As of version 5A, C-Kermit includes support for several networks.
2515 Originally, this was just worked into the ttopen(), ttclos(), ttinc(),
2516 ttinl(), and similar routines in [127]ckutio.c. But this made it
2517 impossible to share this code with non-UNIX versions, like VMS, AOS/VS,
2518 OS/2, etc. So as of edit 168, network code has been separated out into
2519 its own module and header file, ckcnet.c and ckcnet.h:
2521 [128]ckcnet.h: Network-related symbol definitions.
2522 [129]ckcnet.c: Network i/o (TCP/IP, X.25, etc), shared by most
2524 [130]cklnet.c: Network i/o (TCP/IP, X.25, etc) specific to Stratus
2527 The routines and variables in these modules fall into two categories:
2529 1. Support for specific network packages like SunLink X.25 and TGV
2531 2. support for specific network virtual terminal protocols like CCITT
2532 X.3 and TCP/IP Telnet.
2534 Category (1) functions are analogs to the tt*() functions, and have
2535 names like netopen, netclos, nettinc, etc. Group A-D modules do not
2536 (and must not) know anything about these functions -- they continue to
2537 call the old Group E functions (ttopen, ttinc, etc). Category (2)
2538 functions are protocol specific and have names prefixed by a protocol
2539 identifier, like tn for telnet x25 for X.25.
2541 ckcnet.h contains prototypes for all these functions, as well as symbol
2542 definitions for network types, protocols, and network- and protocol-
2543 specific symbols, as well as #includes for the header files necessary
2544 for each network and protocol.
2546 The following functions are to be provided for networks that do not use
2547 normal system i/o (open, read, write, close):
2551 To be called from within ttopen() when a network connection is
2552 requested. Calling conventions and purpose same as Group E
2557 To be called from within ttclos() when a network connection is
2558 being closed. Calling conventions and purpose same as Group E
2563 To be called from within ttchk(). Calling conventions and
2564 purpose same as Group E ttchk().
2568 To be called from within ttflui(). Calling conventions and
2569 purpose same as Group E ttflui().
2573 To send a network break (attention) signal. Calling conventions
2574 and purpose same as Group E ttsndbrk().
2578 To get a character from the network. Calling conventions same as
2583 Send a "character" (byte) to the network. Calling conventions
2584 same as Group E ttoc().
2588 Send a "line" (sequence of bytes) to the network. Calling
2589 conventions same as Group E ttol().
2591 Conceivably, some systems support network connections simply by letting
2592 you open a device of a certain name and letting you do i/o to it.
2593 Others (like the Berkeley sockets TCP/IP library on UNIX) require you
2594 to open the connection in a special way, but then do normal i/o (read,
2595 write). In such a case, you would use netopen(), but you would not use
2596 nettinc, nettoc, etc.
2598 VMS TCP/IP products have their own set of functions for all network
2599 operations, so in that case the full range of netxxx() functions is
2602 The technique is to put a test in each corresponding ttxxx() function
2603 to see if a network connection is active (or is being requested), test
2604 for which kind of network it is, and if necessary route the call to the
2605 corresponding netxxx() function. The netxxx() function must also
2606 contain code to test for the network type, which is available via the
2607 global variable ttnet.
2609 [ [131]Contents ] [ [132]C-Kermit ] [ [133]Kermit Home ]
2611 4.F.1. Telnet Protocol
2613 (This section needs a great deal of updating...)
2615 As of edit 195, Telnet protocol is split out into its own files, since
2616 it can be implemented in remote mode, which does not have a network
2619 [134]ckctel.h: Telnet protocol symbol definitions.
2620 [135]ckctel.c: Telnet protocol.
2622 The Telnet protocol is supported by the following variables and
2626 Nonzero if telnet protocol initialized, zero otherwise.
2630 Initialize the telnet protocol (send initial options).
2634 Send a telnet option.
2638 Receive and act on a telnet option from the remote.
2642 Send terminal type using telnet protocol.
2646 (To be filled in...)
2648 4.F.3. HTTP Protocol
2650 (To be filled in...)
2652 4.F.4. X.25 Networks
2654 These routines were written SunLink X.25 and have since been adapted to
2655 at least on one other: IBM AIXLink/X.25.
2659 Reads and prints X.25 diagnostics
2663 X.25 out of band signal handler
2667 Sends X.25 interrupt packet
2671 Resets X.25 virtual circuit
2675 Clear X.25 virtual circuit
2691 Reads n characters from X.25 circuit.
2695 Read a Kermit packet from X.25 circuit.
2697 [ [136]Contents ] [ [137]C-Kermit ] [ [138]Kermit Home ]
2699 4.F.5. Adding New Network Types
2701 Example: Adding support for IBM X.25 and Hewlett Packard X.25. First,
2702 add new network type symbols for each one. There are already some
2703 network types defined for other X.25 packages:
2705 NET_SX25 is the network-type ID for SunLink X.25.
2706 NET_VX25 is the network-type ID for VOS X.25.
2708 So first you should new symbols for the new network types, giving them
2709 the next numbers in the sequence, e.g.:
2711 #define NET_HX25 11 /* Hewlett-Packard X.25 */
2712 #define NET_IX25 12 /* IBM X.25 */
2714 This is in ckcnet.h.
2716 Then we need symbols to say that we are actually compiling in the code
2717 for these platforms. These would be defined on the cc command line:
2722 So we can build C-Kermit versions for AIX and HP-UX both with and
2723 without X.25 support (since not all AIX and IBM systems have the needed
2724 libraries, and so an executable that was linked with them might no
2737 And then use ANYX25 for code that is common to all of them, and IBMX25
2738 or HPX25 for code specific to IBM or HP.
2740 It might also happen that some code can be shared between two or more
2741 of these, but not the others. Suppose, for example, that you write code
2742 that applies to both IBM and HP, but not Sun or VOS X.25. Then you add
2743 the following definition to ckcnet.h:
2753 #endif /* HPORIBMX25 */
2755 You can NOT use constructions like "#if defined (HPX25 || IBMX25)";
2756 they are not portable.
2758 [ [139]Contents ] [ [140]C-Kermit ] [ [141]Kermit Home ]
2760 4.G. Group G: Formatted Screen Support
2762 So far, this is used only for the fullscreen local-mode file transfer
2763 display. In the future, it might be extended to other uses. The
2764 fullscreen display code is in and around the routine screenc() in
2767 In the UNIX version, we use the curses library, plus one call from the
2768 termcap library. In other versions (OS/2, VMS, etc) we insert dummy
2769 routines that have the same names as curses routines. So far, there are
2770 two methods for simulating curses routines:
2772 1. In VMS, we use the Screen Management Library (SMG), and insert
2773 stubs to convert curses calls into SMG calls.
2774 2. In OS/2, we use the MYCURSES code, in which the stub routines
2775 actually emit the appropriate escape sequences themselves.
2777 Here are the stub routines:
2780 tgetent(char *buf, char *term)
2781 Arguments are ignored. Returns 1 if the user has a supported
2782 terminal type, 0 otherwise. Sets a global variable (for example,
2783 "isvt52" or "isdasher") to indicate the terminal type.
2786 move(int row, int col)
2787 Sends the escape sequence to position the cursor at the
2788 indicated row and column. The numbers are 0-based, e.g. the home
2793 Sends the escape sequence to clear the screen.
2797 Sends the escape sequence to clear from the current cursor
2798 position to the end of the line.
2800 In the MYCURSES case, code must be added to each of the last three
2801 routines to emit the appropriate escape sequences for a new terminal
2804 clearok(curscr), wrefresh()
2805 In real curses, these two calls are required to refresh the
2806 screen, for example after it was fractured by a broadcast
2807 message. These are useful only if the underlying screen
2808 management service keeps a copy of the entire screen, as curses
2809 and SMG do. C-Kermit does not do this itself.
2811 [ [143]Contents ] [ [144]C-Kermit ] [ [145]Kermit Home ]
2813 4.H. Group H: Pseudoterminal Support
2815 (To be filled in...)
2817 4.I. Group I: Security
2819 (To be filled in...)
2821 [ [146]Contents ] [ [147]C-Kermit ] [ [148]Kermit Home ]
2823 APPENDIX I. FILE PERMISSIONS
2825 I.1. Format of System-Dependent File Permissions in A-Packets
2827 The format of this field (the "," attribute) is interpreted according
2828 to the System ID ("." Attribute).
2830 For UNIX (System ID = U1), it's the familiar 3-digit octal number, the
2831 low-order 9 bits of the filemode: Owner, Group, World, e.g. 660 =
2832 read/write access for owner and group, none for world, recorded as a
2833 3-digit octal string. High-order UNIX permission bits are not
2836 For VMS (System ID = D7), it's a 4-digit hex string, representing the
2837 16-bit file protection WGOS fields (World,Group,Owner,System), in that
2838 order (which is the reverse of how they're shown in a directory
2839 listing); in each field, Bit 0 = Read, 1 = Write, 2 = Execute, 3 =
2840 Delete. A bit value of 0 means permission is granted, 1 means
2841 permission is denied. Sample:
2843 r-01-00-^A/!FWERMIT.EXE'"
2844 s-01-00-^AE!Y/amd/watsun/w/fdc/new/wermit.exe.DV
2845 r-02-01-^A]"A."D7""B8#119980101 18:14:05!#8531&872960,$A20B-!7(#512@ #.Y
2848 A VMS directory listing shows the file's protection as (E,RWED,RED,RE)
2849 which really means (S=E,O=RWED,G=RED,W=RE), which is reverse order from
2850 the internal storage, so (RE,RED,RWED,E). Now translate each letter to
2851 its corresponding bit:
2853 RE=0101, RED=1101, RWED=1111, E=0010
2855 Now reverse the bits:
2857 RE=1010, RED=0010, RWED=0000, E=1101
2859 This gives the 16-bit quantity:
2863 This is the internal representation of the VMS file permission; in hex:
2867 as shown in the sample packet above.
2869 The VMS format probably would also apply to RSX or any other FILES-11
2872 I.2. Handling of Generic Protection
2874 To be used when the two systems are different (and/or do not recognize
2875 or understand each other's local protection codes).
2877 First of all, the book is wrong. This should not be the World
2878 protection, but the Owner protection. The other fields should be set
2879 according to system defaults (e.g. UNIX umask, VMS default protection,
2880 etc), except that no non-Owner field should give more permissions than
2883 [ [149]Top ] [ [150]Contents ] [ [151]C-Kermit Home ] [ [152]Kermit
2885 __________________________________________________________________
2888 C-Kermit Program Logic Manual / [153]The Kermit Project /
2889 [154]kermit@columbia.edu / 30 June 2011
2893 1. http://www.columbia.edu/
2894 2. mailto:kermit@columbia.edu
2895 3. http://www.columbia.edu/kermit/index.html
2896 4. http://www.columbia.edu/kermit/k95.html
2897 5. http://www.columbia.edu/kermit/ckermit.html
2898 6. http://www.columbia.edu/kermit/ckscripts.html
2899 7. http://www.columbia.edu/kermit/current.html
2900 8. http://www.columbia.edu/kermit/whatsnew.html
2901 9. http://www.columbia.edu/kermit/ckfaq.html
2902 10. http://www.columbia.edu/kermit/support.html
2903 11. http://www.columbia.edu/kermit/
2904 12. http://www.columbia.edu/
2905 13. http://www.columbia.edu/kermit/ckcplm.html
2906 14. http://www.columbia.edu/kermit/ckermit.html
2907 15. http://www.columbia.edu/kermit/index.html
2908 16. http://www.columbia.edu/kermit/ckcplm.html#x1
2909 17. http://www.columbia.edu/kermit/ckcplm.html#x2
2910 18. http://www.columbia.edu/kermit/ckcplm.html#x3
2911 19. http://www.columbia.edu/kermit/ckcplm.html#x4
2912 20. http://www.columbia.edu/kermit/ckcplm.html#x4.A
2913 21. http://www.columbia.edu/kermit/ckcplm.html#x4.B
2914 22. http://www.columbia.edu/kermit/ckcplm.html#x4.C
2915 23. http://www.columbia.edu/kermit/ckcplm.html#x4.D
2916 24. http://www.columbia.edu/kermit/ckcplm.html#x4.E
2917 25. http://www.columbia.edu/kermit/ckcplm.html#x4.F
2918 26. http://www.columbia.edu/kermit/ckcplm.html#x4.G
2919 27. http://www.columbia.edu/kermit/ckcplm.html#x4.H
2920 28. http://www.columbia.edu/kermit/ckcplm.html#x4.I
2921 29. http://www.columbia.edu/kermit/ckcplm.html#xa1
2922 30. http://www.columbia.edu/kermit/ckcplm.html#contents
2923 31. http://www.columbia.edu/kermit/ckcplm.html#contents
2924 32. http://www.columbia.edu/kermit/ckermit.html
2925 33. http://www.columbia.edu/kermit/index.html
2926 34. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.w
2927 35. http://www.columbia.edu/kermit/ckcplm.html#contents
2928 36. http://www.columbia.edu/kermit/ckermit.html
2929 37. http://www.columbia.edu/kermit/index.html
2930 38. http://www.columbia.edu/kermit/ckcplm.html#x3.2
2931 39. http://www.columbia.edu/kermit/ckcplm.html#contents
2932 40. http://www.columbia.edu/kermit/ckermit.html
2933 41. http://www.columbia.edu/kermit/index.html
2934 42. http://www.columbia.edu/kermit/ckcplm.html#x4.A
2935 43. http://www.columbia.edu/kermit/ckcplm.html#contents
2936 44. http://www.columbia.edu/kermit/ckermit.html
2937 45. http://www.columbia.edu/kermit/index.html
2938 46. http://www.columbia.edu/kermit/ckcplm.html#contents
2939 47. http://www.columbia.edu/kermit/ckermit.html
2940 48. http://www.columbia.edu/kermit/index.html
2941 49. http://www.columbia.edu/kermit/ckcplm.html#contents
2942 50. http://www.columbia.edu/kermit/ckermit.html
2943 51. http://www.columbia.edu/kermit/index.html
2944 52. ftp://kermit.columbia.edu/kermit/c-kermit/ckclib.h
2945 53. ftp://kermit.columbia.edu/kermit/c-kermit/ckclib.c
2946 54. http://www.columbia.edu/kermit/ckcplm.html#x3.1
2947 55. http://www.columbia.edu/kermit/ckcplm.html#contents
2948 56. http://www.columbia.edu/kermit/ckermit.html
2949 57. http://www.columbia.edu/kermit/index.html
2950 58. ftp://kermit.columbia.edu/kermit/c-kermit/ckcsym.h
2951 59. ftp://kermit.columbia.edu/kermit/c-kermit/ckcasc.h
2952 60. ftp://kermit.columbia.edu/kermit/c-kermit/ckcsig.h
2953 61. ftp://kermit.columbia.edu/kermit/c-kermit/ckcdeb.h
2954 62. ftp://kermit.columbia.edu/kermit/c-kermit/ckcker.h
2955 63. ftp://kermit.columbia.edu/kermit/c-kermit/ckcxla.h
2956 64. ftp://kermit.columbia.edu/kermit/c-kermit/ckcmai.c
2957 65. ftp://kermit.columbia.edu/kermit/c-kermit/ckcpro.w
2958 66. ftp://kermit.columbia.edu/kermit/c-kermit/ckcfns.c
2959 67. ftp://kermit.columbia.edu/kermit/c-kermit/ckcfn2.c
2960 68. ftp://kermit.columbia.edu/kermit/c-kermit/ckcfn3.c
2961 69. http://www.columbia.edu/kermit/ckcplm.html#x4.B
2962 70. http://www.columbia.edu/kermit/ckcplm.html#x4.E
2963 71. http://www.columbia.edu/kermit/ckcplm.html#x4.D
2964 72. http://www.columbia.edu/kermit/ckcplm.html#contents
2965 73. http://www.columbia.edu/kermit/ckermit.html
2966 74. http://www.columbia.edu/kermit/index.html
2967 75. http://www.columbia.edu/kermit/ckcplm.html#x4.B
2968 76. ftp://kermit.columbia.edu/kermit/c-kermit/ckuxla.c
2969 77. ftp://kermit.columbia.edu/kermit/c-kermit/ckuxla.h
2970 78. ftp://kermit.columbia.edu/kermit/c-kermit/ckcxla.h
2971 79. ftp://kermit.columbia.edu/kermit/c-kermit/ckuxla.h
2972 80. ftp://kermit.columbia.edu/kermit/c-kermit/ckmxla.h
2973 81. ftp://kermit.columbia.edu/kermit/c-kermit/ck?xla
2974 82. ftp://kermit.columbia.edu/kermit/c-kermit/ckcuni.h
2975 83. ftp://kermit.columbia.edu/kermit/c-kermit/ckcuni.c
2976 84. http://www.columbia.edu/kermit/ckcplm.html#contents
2977 85. http://www.columbia.edu/kermit/ckermit.html
2978 86. http://www.columbia.edu/kermit/index.html
2979 87. http://www.columbia.edu/kermit/ckcplm.html#x4.B
2980 88. ftp://kermit.columbia.edu/kermit/c-kermit/ckucmd.h
2981 89. ftp://kermit.columbia.edu/kermit/c-kermit/ckucmd.c
2982 90. http://www.columbia.edu/kermit/ckcplm.html#x4.E
2983 91. ftp://kermit.columbia.edu/kermit/c-kermit/ckuusr.h
2984 92. ftp://kermit.columbia.edu/kermit/c-kermit/ckuusr.c
2985 93. ftp://kermit.columbia.edu/kermit/c-kermit/ckuus2.c
2986 94. ftp://kermit.columbia.edu/kermit/c-kermit/ckuus3.c
2987 95. ftp://kermit.columbia.edu/kermit/c-kermit/ckuus4.c
2988 96. ftp://kermit.columbia.edu/kermit/c-kermit/ckuusy.c
2989 97. ftp://kermit.columbia.edu/kermit/c-kermit/ckuusx.c
2990 98. ftp://kermit.columbia.edu/kermit/c-kermit/ckuver.h
2991 99. ftp://kermit.columbia.edu/kermit/c-kermit/ckuscr.c
2992 100. ftp://kermit.columbia.edu/kermit/c-kermit/ckudia.c
2993 101. ftp://kermit.columbia.edu/kermit/c-kermit/ckucon.c
2994 102. ftp://kermit.columbia.edu/kermit/c-kermit/ckucns.c
2995 103. http://www.columbia.edu/kermit/ckcplm.html#x4.E
2996 104. ftp://kermit.columbia.edu/kermit/c-kermit/ckcmai.c
2997 105. http://www.columbia.edu/kermit/ckcplm.html#contents
2998 106. http://www.columbia.edu/kermit/ckermit.html
2999 107. http://www.columbia.edu/kermit/index.html
3000 108. ftp://kermit.columbia.edu/kermit/c-kermit/ckufio.c
3001 109. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
3002 110. ftp://kermit.columbia.edu/kermit/c-kermit/ckusig.c
3003 111. ftp://kermit.columbia.edu/kermit/c-kermit/ckvfio.c
3004 112. ftp://kermit.columbia.edu/kermit/c-kermit/ckusig.c
3005 113. ftp://kermit.columbia.edu/kermit/c-kermit/ckcmai.c
3006 114. http://www.columbia.edu/kermit/ckcplm.html#contents
3007 115. http://www.columbia.edu/kermit/ckermit.html
3008 116. http://www.columbia.edu/kermit/index.html
3009 117. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
3010 118. ftp://kermit.columbia.edu/kermit/c-kermit/ckvtio.c
3011 119. http://www.columbia.edu/kermit/ckcplm.html#x2
3012 120. http://www.columbia.edu/kermit/ckcplm.html#xa1
3013 121. http://www.columbia.edu/kermit/ckuins.html
3014 122. ftp://kermit.columbia.edu/kermit/c-kermit/ckcnet.h
3015 123. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
3016 124. http://www.columbia.edu/kermit/ckcplm.html#contents
3017 125. http://www.columbia.edu/kermit/ckermit.html
3018 126. http://www.columbia.edu/kermit/index.html
3019 127. ftp://kermit.columbia.edu/kermit/c-kermit/ckutio.c
3020 128. ftp://kermit.columbia.edu/kermit/c-kermit/ckcnet.h
3021 129. ftp://kermit.columbia.edu/kermit/c-kermit/ckcnet.c
3022 130. ftp://kermit.columbia.edu/kermit/c-kermit/cklnet.c
3023 131. http://www.columbia.edu/kermit/ckcplm.html#contents
3024 132. http://www.columbia.edu/kermit/ckermit.html
3025 133. http://www.columbia.edu/kermit/index.html
3026 134. ftp://kermit.columbia.edu/kermit/c-kermit/ckctel.h
3027 135. ftp://kermit.columbia.edu/kermit/c-kermit/ckctel.c
3028 136. http://www.columbia.edu/kermit/ckcplm.html#contents
3029 137. http://www.columbia.edu/kermit/ckermit.html
3030 138. http://www.columbia.edu/kermit/index.html
3031 139. http://www.columbia.edu/kermit/ckcplm.html#contents
3032 140. http://www.columbia.edu/kermit/ckermit.html
3033 141. http://www.columbia.edu/kermit/index.html
3034 142. ftp://kermit.columbia.edu/kermit/c-kermit/ckuusx.c
3035 143. http://www.columbia.edu/kermit/ckcplm.html#contents
3036 144. http://www.columbia.edu/kermit/ckermit.html
3037 145. http://www.columbia.edu/kermit/index.html
3038 146. http://www.columbia.edu/kermit/ckcplm.html#contents
3039 147. http://www.columbia.edu/kermit/ckermit.html
3040 148. http://www.columbia.edu/kermit/index.html
3041 149. http://www.columbia.edu/kermit/ckcplm.html#top
3042 150. http://www.columbia.edu/kermit/ckcplm.html#contents
3043 151. http://www.columbia.edu/kermit/ckermit.html
3044 152. http://www.columbia.edu/kermit/index.html
3045 153. http://www.columbia.edu/kermit/index.html
3046 154. mailto:kermit@columbia.edu