C-Kermit and Plan 9
Frank da Cruz
Hi Plan 9 people. I'm the Kermit guy. I'm working on a new release of
C-Kermit (communications software, serial and TCP/IP; terminal connection,
file transfer, character-set translation, scripting), which to date has been
adapted to about 700 different platforms, but so far not yet to Plan 9.
Since Plan 9 is supposed to include POSIX APIs and a sockets library, which
C-Kermit already supports, I thought it would be worth trying to see if
C-Kermit could be built there, or what it would take to make it build.
Anybody want to take a shot at this? Or, alternatively, does anyone have a
Plan 9 system that I could get telnet and ftp access to, and do it myself?
Thanks!
Frank da Cruz
Manager
Communications Software Development
Columbia University
612 West 115th Street
New York NY 10025-7721
USA
Email: f...@columbia.edu
Nigel Roles
> Anybody want to take a shot at this? Or, alternatively, does anyone have a
> Plan 9 system that I could get telnet and ftp access to, and do it myself?
>
>
Go on then. Tell me where the source is. I'll do it.
Nigel Roles
Frank da Cruz
In article <960924070...@symbionics.co.uk>,
Nigel Roles <n...@symbionics.co.uk> wrote:
: > Anybody want to take a shot at this? Or, alternatively, does anyone have a
: > Plan 9 system that I could get telnet and ftp access to, and do it myself?
: >
: Go on then. Tell me where the source is. I'll do it.
The easy way to get started it is to get the C-Kermit 6.0 Beta (which is
still changing every couple weeks, but not too much) at:
ftp://kermit.columbia.edu/kermit/test/tar/cku192.tar.gz (or .Z)
Then uncompress, untar, "make posix" and see what comes out. If there are
errors and you don't want to track them down, email the log to me.
If that works out, try adding TCP/IP (e.g. Telnet client/server) support:
make posix "KFLAGS=-DTCPSOCKET" "LIBS=???"
and/or also curses support (if Plan 9 has such a thing):
make posix "KFLAGS=-DCK_CURSES" "LIBS=-lcurses -ltermcap" (or whatever)
There is no end of possibilities. Some initial reading:
ckcplm.doc - Program logic manual
ckccfg.doc - Configuration options
ckuins.doc - UNIX installation instructions
makefile - Has lots of comments
Anybody who starts working on this should let me know, not only so I can
answer questions, etc, but also prevent any duplication of effort.
Naturally, it would be more interesting -- and no doubt also a lot more
work -- to adapt C-Kermit to native Plan 9 operation, rather than POSIX/BSD
emulation; for example, the file-system model for Internet connection --
if indeed that could apply to a communications program.
Also, please note that C-Kermit -- in order to be portable to so many
different platforms, some of them going back a good 20 years (e.g. 7th
Edition UNIX) is a simple C program (with compile-time options for ANSIness
-- but it has to be able to go either way: "all that is not forbidden is
required"). In particular, that means regular old null-terminated strings
of single-byte characters. No locales, no wchar_t, none of that, because
such things are not portable. I don't know what the implications of this
might be for a Unicode based system like Plan 9 (?).
Thanks!
- Frank
Doug Gwyn
In article <528pg0$q...@apakabar.cc.columbia.edu> f...@watsun.cc.columbia.EDU (Frank da Cruz) writes:
>Naturally, it would be more interesting -- and no doubt also a lot more
>work -- to adapt C-Kermit to native Plan 9 operation, rather than POSIX/BSD
>emulation; for example, the file-system model for Internet connection --
>if indeed that could apply to a communications program.
On Plan 9, if an app can handle arbitrary "local" files by pathname,
it automatically has access to any network resources supported by the
system. That's sort of the central notion..
>... that means regular old null-terminated strings of single-byte characters.
>No locales, no wchar_t, none of that, because such things are not portable.
>I don't know what the implications of this might be for a Unicode based
>system like Plan 9 (?).
Actually, without support for locales and non-ASCII charsets, the app isn't
portable anyway! It would make more sense to use the I20n features and
provide a minimal library implementation of the I20n interface for use on
platforms that don't provide their own.
As to the use in a Unicode environment, the quickest hack would be to use
UTF-FSS strings, which has ASCII embedded as a subset (non-ASCII codes are
represented as escape sequences, in effect).
Frank da Cruz
In article <1996Sep24....@arl.mil>, Doug Gwyn <gw...@arl.MIL> wrote:
: Actually, without support for locales and non-ASCII charsets, the app isn't
: portable anyway! It would make more sense to use the I20n features and
: provide a minimal library implementation of the I20n interface for use on
: platforms that don't provide their own.
:
Approximately 743 of them would be needed, at last count. For C-Kermit,
portability does not mean compliance with Buzzword 1.0, but the ability to
be built on the widest range of platforms using their native tools --
compilers, libraries, system calls, etc. As soon as you add in a dependence
on I20n, you lose the ability to build it on countless systems where it once
worked, at least until the needed libraries are ported there, if that is
even possible since I would not be surprised if they were written in an
advanced dialect of C that assumes features (e.g. ANSI prototyping) that are
not found in many environments.
At some point, I will need to add explicit Unicode support to Kermit (as
another file and/or transfer character set -- in addition to the many Roman,
Cyrillic, Hebrew, Kanji, etc, character sets it already supports), but that
is entirely a different matter from supporting (or assuming) Unicode as the
codeset of the source language itself.
: As to the use in a Unicode environment, the quickest hack would be to use
: UTF-FSS strings, which has ASCII embedded as a subset (non-ASCII codes are
: represented as escape sequences, in effect).
:
Kind of like ISO 2022, exactly what Unicode was trying to replace :-)
- Frank
Doug Gwyn
In article <52bcpa$n...@apakabar.cc.columbia.edu> f...@watsun.cc.columbia.EDU (Frank da Cruz) writes:
>In article <1996Sep24....@arl.mil>, Doug Gwyn <gw...@arl.MIL> wrote:
>: Actually, without support for locales and non-ASCII charsets, the app isn't
>: portable anyway! It would make more sense to use the I20n features and
>: provide a minimal library implementation of the I20n interface for use on
>: platforms that don't provide their own.
>Approximately 743 of them would be needed, at last count.
That's nonsense! It is possible to produce a *single* minimalist interface
written entirely in Standard C minus the I18n features (Okay, so I can't
count the letters in long words!), or even so-called "K&R C". It would be
limited to supporting just the "C" locale, but that's what you're limited
to anyway on the platforms for which this "stub" library would be used.
>: As to the use in a Unicode environment, the quickest hack would be to use
>: UTF-FSS strings, which has ASCII embedded as a subset (non-ASCII codes are
>: represented as escape sequences, in effect).
>Kind of like ISO 2022, exactly what Unicode was trying to replace :-)
I'm not sure what relevance that comment was supposed to have. You stated
a concern over how to port to Plan 9 without adapting the app to use the
standard I18n facilities. Because the actual byte strings are UTF-FSS
encoded, you should be able to use them in your app "as is". Most Plan 9
filenames are likely to consist entirely of 7-bit ASCII characters, which
is a subset of UTF-FSS strings. There is essentially no work needed to
take advantage of this property.
Frank da Cruz
In article <1996Sep26.2...@arl.mil>, Doug Gwyn <gw...@arl.MIL> wrote:
: In article <52bcpa$n...@apakabar.cc.columbia.edu> f...@watsun.cc.columbia.EDU
: (Frank da Cruz) writes:
: >In article <1996Sep24....@arl.mil>, Doug Gwyn <gw...@arl.MIL> wrote:
: >: Actually, without support for locales and non-ASCII charsets, the app
: >: isn't portable anyway! It would make more sense to use the I20n features
: >: and provide a minimal library implementation of the I20n interface for
: >: use on platforms that don't provide their own.
: >Approximately 743 of them would be needed, at last count.
:
: That's nonsense! It is possible to produce a *single* minimalist interface
: written entirely in Standard C minus the I18n features (Okay, so I can't
: count the letters in long words!), or even so-called "K&R C". It would be
: limited to supporting just the "C" locale, but that's what you're limited
: to anyway on the platforms for which this "stub" library would be used.
:
: >: As to the use in a Unicode environment, the quickest hack would be to use
: >: UTF-FSS strings, which has ASCII embedded as a subset (non-ASCII codes are
: >: represented as escape sequences, in effect).
: >
: >Kind of like ISO 2022, exactly what Unicode was trying to replace :-)
:
: I'm not sure what relevance that comment was supposed to have.
:
It was a joke :-)
: You stated a concern over how to port to Plan 9 without adapting the app to
: use the standard I18n facilities. Because the actual byte strings are
: UTF-FSS encoded, you should be able to use them in your app "as is". Most
: Plan 9 filenames are likely to consist entirely of 7-bit ASCII characters,
: which is a subset of UTF-FSS strings. There is essentially no work needed
: to take advantage of this property.
:
That's encouraging, thanks.
Anyway, I'm not here to make trouble -- I'd like to have C-Kermit ported to
Plan 9. I'd be glad to (try to) do it myself, but I don't have access to a
Plan 9 platform. I know I could get Plan 9 and install it locally, but it
would be a lot faster if there were a Plan 9 system I could telnet & ftp to.
So has anyone tried building it yet? Again, it's at:
ftp://kermit.columbia.edu/kermit/test/tar/cku192.tar.gz (and .Z)
Uncompress, untar, "make posix" (for a start).
- Frank
Mark A Harrison
Doug Gwyn (gw...@arl.MIL) wrote:
: It would make more sense to use the I20n features and
: provide a minimal library implementation of the I20n interface for use on
: platforms that don't provide their own.
I hate to sound dumb, but what is I20n... Is it somehow related
to I18n?
--
Mark Harrison http://jasper.ora.com/mh/
Doug Gwyn
In article <52klih$2...@news.utdallas.edu> mhar...@utdallas.EDU (Mark A Harrison) writes:
>Doug Gwyn (gw...@arl.MIL) wrote:
>I hate to sound dumb, but what is I20n... Is it somehow related to I18n?
I guess it's I18n with the boundaries included. Sorry about that..
Doug Gwyn
In article <52h53j$c...@apakabar.cc.columbia.edu> f...@watsun.cc.columbia.EDU (Frank da Cruz) writes:
>: It is possible to produce a *single* minimalist interface
>: written entirely in Standard C minus the I18n features,
>: or even so-called "K&R C".
>: to anyway on the platforms for which this "stub" library would be used.
>So does such a stub library exist? Has anyone done this sort of thing before?
I used to do a lot of this kind of implementation (putting the result into
the public domain for others to use), but I don't think I have management
support these days for spending much time on such things.
I don't know of any implementation of that specific library, but it's mainly
a matter of providing the extra pieces of standard header defining the I18n
interface (such as "typedef unsigned char wchar_t;" in <stddef.h>) and the
library code for a handful of functions. To do the job right, one should
include the C Standard's whole "normative addendum" interface, which would
then be used in the application in place of the parochial versions of the
same functionality. The need to do this was evident when X3J11 first
decided to have the equivalents of both wchar_t and char[] escape sequences,
instead of a single "universal" character type. A better design, in my
opinion, would have been to distinguish between text streams and binary
streams, which distinction was made later anyway in the normative
addendums "wide character streams". While I am not a big fan of this
design, at least there is a standard API for it.
Simple example of how the "stubs" can be implemented:
/* <wctype.h> */
#ifndef __WCTYPE_H_INCLUDED
#define __WCTYPE_H_INCLUDED
typedef int wint_t;
typedef int wctrans_t;
typedef int wctype_t;
#define WEOF (-1) /* must match definition of EOF */
/* ... */
extern int iswdigit(wint_t wc);
/* ... */
#endif
/* iswdigit() */
#include <wctype.h>
#include <ctype.h>
int iswdigit(wint_t wc) { return isdigit(wc); }
Then in the application, change:
/* ... */
#include <ctype.h>
/* ... */
bool validate_decimal_number(const char *s) {
if (*s == '\0')
return false;
for ( ; *s != '\0'; ++s)
if (!isdigit(*s))
return false;
return true;
}
to:
/* ... */
#include <stddef.h>
#include <wctype.h>
/* ... */
bool validate_decimal_number(const wchar_t *s) {
if (*s == '\0')
return false;
for ( ; *s != '\0'; ++s)
if (!iswdigit(*s))
return false;
return true;
}
It should be evident that most such application code editing
can be automated. (The main thing to watch out for is use of
"char" for non-character data, e.g. byte manipulation.)
The revised application could then be linked with the real functions
in an evironment that truly supports international character sets
via the C Standard's interface for this purpose, or linked with the
"stub" library in all other environments.