dls@genco.bungi.com (Dave L. Smith) (05/13/91)
I have tried all sorts of contortions with rz/sz to make them work from within cu on SCO Xenix 386, with no luck. Does anyone have any ideas? Thanks, Dave Smith
vandys@sequent.com (Andrew Valencia) (05/14/91)
dls@genco.bungi.com (Dave L. Smith) writes: >I have tried all sorts of contortions with rz/sz to make them work from >within cu on SCO Xenix 386, with no luck. Does anyone have any ideas? I wrote a simple terminal program which knew how to push out to do [xyz]modem. It's a hundred lines or so; I can post it if people are interested in this sort of solution. Andy Valencia vandys@sequent.com
osvaldo@sos.com (Osvaldo Gold) (05/14/91)
In article <677@genco.bungi.com> dls@genco.bungi.com (Dave L. Smith) writes: >I have tried all sorts of contortions with rz/sz to make them work from >within cu on SCO Xenix 386, with no luck. Does anyone have any ideas? Try this. It works for me under ODT 1.1. Allow me to give my example using xmodem since I don't remember how the rz/sz combo works. Initiate the cu session to the remote system. Start "xmodem -sb filename" at the remote system. Quickly start a shell on the local system with ~!, get root permissions and type: # xmodem -rb filename < /dev/tty1a > /dev/tty1a Substitute your ttys here, of course. Make sure you redirect both the stdin and the stdout. Make sure you have root permissions too otherwise you can't get to the ttys (they are open with exclusive access (?)). If you are on the console you could just switch multiscreens to give this command instead of going through the anxiety of typing fast before the remote xmodem times out. Voila. Should work. -- ----------------------------------------------------------------- Osvaldo Gold osvaldo@sos.com ...[uunet]!uupsi!sos.com!osvaldo These opinions are only my own. SOS has nothing to do with them.
vandys@sequent.com (Andrew Valencia) (05/14/91)
dls@genco.bungi.com (Dave L. Smith) writes: >I have tried all sorts of contortions with rz/sz to make them work from >within cu on SCO Xenix 386, with no luck. Does anyone have any ideas? Well, I've already received enough requests that I'm going to post this here. I know it's source, but it's a very modest C program so I hope nobody'll get too mad. It's public domain, I wrote it from scratch, so make your millions from it if you can! Enjoy, Andy Valencia vandys@sequent.com # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by vandys on Mon May 13 21:45:15 PDT 1991 # Contents: Makefile term.1 term.c echo x - Makefile sed 's/^@//' > "Makefile" <<'@//E*O*F Makefile//' CFLAGS= -O # -g for debugging OBJS= term.o term: $(OBJS) $(CC) $(CFLAGS) -o term $(OBJS) @//E*O*F Makefile// chmod u=rw,g=r,o=r Makefile echo x - term.1 sed 's/^@//' > "term.1" <<'@//E*O*F term.1//' @.TH TERM 1 "Public Domain" "" "5/91" @.SH NAME term \- provide simple terminal interface to serial port @.SH SYNOPSIS @.B term @.RB "[ " \-s speed" ] [ " @.RB "[ " \-p proto" ] [ " @.BR "device ] " @.SH DESCRIPTION @.B term\^ allows a user to open a TTY device and run an interactive session through it. It provides similar facilities to @.B cu(1), but is useful in cases where access to auxilary protocol programs is desired or further customization of the source code is needed. @.TP @.B \-s is used to specify the baud rate the serial port should be set to; the default is 9600 baud. Legal values are 300, 1200, 2400, and 9600. @.TP @.B \-p selects which file transfer protocol (see below) is to be used. The default is 'z' for Z-modem; legal values are 'x', 'y', or 'z'. @.PP The final argument, @.B device, specifies which serial port to access. It should spell out the complete path to the desired device. The default is @.B /dev/tty1a on XENIX, and @.B /dev/tty01 on other breeds of UNIX. @.PP On startup @.B term goes into interactive mode immediately. All extended commands are accessed by first typing ^U (control-U), then a command character. Typing a second ^U merely sends a ^U to the remote system. Typing 'r' starts a file transfer @.I receive. Typing 's' starts a file transfer @.I send. Typing 'q' causes the terminal program to clean up and exit. Any other character causes a brief summary of the commands to be displayed. @.SH FILE TRANSFERS The @.B term(1) program itself has no knowledge of file transfers. It merely builds a command line which it then launches on the host operating system. The commands "rx", "ry", and "rz" must be in the user's path for X- Y- and Z-modem file transfer receives. "sx", "sy", and "sz" are needed similarly for file transfer sends. Chuck Forsberg's excellent public domain Z-modem implementation is known to work beautifully with @.B term(1). @.SH FILES /dev/tty?? rx, ry, rz sx, sy, sz @.SH SEE ALSO cu(1) @.SH NOTES XENIX is a registered trademark of The Santa Cruz Operation, Inc. @.sp UNIX is a registered trademark of AT&T. @//E*O*F term.1// chmod u=rw,g=r,o= term.1 echo x - term.c sed 's/^@//' > "term.c" <<'@//E*O*F term.c//' /* * term.c * Terminal utility for banging characters out a serial port */ #include <sys/types.h> #include <sys/fcntl.h> #include <stdio.h> #include <termio.h> #include <signal.h> #include <errno.h> static struct termio ntty, otty, ext; static int baud = B9600; static int ext_cmd(); int ttyfd, /* File descriptor of TTY port */ rs232; /* ...and of RS-232 port */ #define CMD_CHAR '\25' /* Control-U starts protocol transfer */ /* * Protocols to receive under */ #define PROTO_RX 1 #define PROTO_RY 2 #define PROTO_RZ 3 static int proto = PROTO_RZ; /* Default--zmodem */ /* * usr2() * Handle SIGUSR2 signal * * Doesn't do anything except re-arm the handler because interrupting * the system call is the whole point. */ usr2() { signal(SIGUSR2, usr2); } /* * usr1() * Handle SIGUSR1 signal * * Puts us to sleep until we're kicked back by a SIGUSR2 */ usr1() { signal(SIGUSR1, usr1); pause(); } main(argc, argv) int argc; char **argv; { register char *p, *q; int child, code; int x; char buf[30]; char c; #ifdef XENIX char *tty = "/dev/tty1a"; /* XENIX default */ #else char *tty = "/dev/tty01"; /* Microport/ATT default */ #endif for( x = 1; x < argc; ++x ){ if (argv[x][0] == '-') { c = argv[x][1]; if (argv[x][2]) p = argv[x]+2; else p = argv[++x]; switch( c ){ /* * Selection of baud rate */ case 's': if (!strcmp(p, "300")) { baud = B300; break; } if (!strcmp(p, "1200")) { baud = B1200; break; } if (!strcmp(p, "2400")) { baud = B2400; break; } if (!strcmp(p, "9600")) { baud = B9600; break; } printf("Illegal speed: %s\n",p); break; /* * Selection of transfer protocol */ case 'p': if (!strcmp(p, "x")) { proto = PROTO_RX; break; } if (!strcmp(p, "y")) { proto = PROTO_RY; break; } if (!strcmp(p, "z")) { proto = PROTO_RZ; break; } printf("Illegal protocol: %s\n", p); break; default: printf("Illegal option: %c\n", c); printf("Usage is: %s [-s <speed>] [-p <protocol>] [<tty>]\n", argv[0]); break; } } else tty = argv[x]; } /* * The next bit of code makes assumptions about * how UNIX manages its file descriptors. The goal * is to make the terminal device be our standard * input & output. */ ttyfd = dup(1); close(0); close(1); if ((rs232 = open(tty, O_RDWR|O_EXCL)) < 0) { perror(tty); exit(1); } dup(rs232); /* * Set up for raw TTY I/O */ ioctl(ttyfd, TCGETA, &otty); ioctl(ttyfd, TCGETA, &ntty); ntty.c_lflag &= ~(ECHO|ICANON|ISIG); ntty.c_oflag &= ~OPOST; ntty.c_iflag = 0; ntty.c_cc[VMIN] = 1; ntty.c_cc[VTIME] = 0; ioctl(ttyfd, TCSETAW, &ntty); /* * Set up serial port for raw access too */ ioctl(rs232, TCGETA, &ext); ext.c_lflag &= ~(ECHO|ICANON|ISIG); ext.c_cflag = (ext.c_cflag & ~CBAUD) | baud; ext.c_oflag &= ~OPOST; ext.c_iflag = 0; ext.c_cc[VMIN] = sizeof(buf); ext.c_cc[VTIME] = 1; ioctl(rs232, TCSETAW, &ext); /* * Launch child. Child reads RS-232 and writes TTY. The * child is also the half which is knocked asleep during * protocol file transfers. */ if ((child = fork()) == 0) { static char boot_msg[] = "Term ready for action!\r\n"; signal(SIGUSR1, usr1); signal(SIGUSR2, usr2); write(ttyfd, boot_msg, sizeof(boot_msg)-1); for (;;) { if ((x = read(rs232, buf, sizeof(buf))) < 0 ) { if (errno == EINTR) continue; perror("child"); exit(1); } p = buf; q = buf+x; while (p < q) *p++ &= 0x7F; write(ttyfd, buf, x); } } /* * Launch of child failed. Restore TTY and leave. */ if (child < 0) { ioctl(ttyfd, TCSETAW, &otty); perror("child fork"); exit(1); } /* * Parent loop. Read chars until device dies or we break out * on exit. */ while ((code = read(ttyfd, &c, 1)) == 1) { c &= 0x7F; /* CMD_CHAR (usually Control-U) starts file transfers */ if (c == CMD_CHAR) { kill(child, SIGUSR1); /* * Extended command returns non-zero when * quit selected. */ if (ext_cmd()) break; kill(child, SIGUSR2); continue; } if (c == '\n') c = '\r'; write(rs232, &c, 1); } if (code < 0) perror("parent"); /* * Finish up. Nuke the child, restore TTY, exit */ kill(child, SIGKILL); ioctl(ttyfd, TCSETAW, &otty); write(ttyfd, "Exiting\n", 8); exit(0); /*NOTREACHED*/ } /* * prompt_read() * Ask for and receive a line in raw mode */ static void prompt_read(prompt, buf, len) char *prompt; register char *buf; register int len; { char c; /* Leave room for null terminator */ len -= 1; /* Prompt */ write(ttyfd, prompt, strlen(prompt)); /* Read chars until newline */ do { while (read(ttyfd, &c, sizeof(c)) == 0) ; c &= 0x7F; write(ttyfd, &c, sizeof(c)); if (len) { *buf++ = c; --len; } } while ((c != '\n') && (c != '\r')); /* Overwrite newline with terminator */ buf -= 1; *buf = '\0'; } /* * rx_xfer() * Execute a protocol receive */ static void rx_xfer() { char buf[80]; char fname[60]; switch (proto) { case PROTO_RX: /* * Xmodem doesn't send names, so we have to ask. Bleh. */ prompt_read("Receive file: ", fname, sizeof(fname)); sprintf(buf, "rx %s", fname); break; case PROTO_RY: strcpy(buf, "ry"); break; case PROTO_RZ: default: strcpy(buf, "rz"); break; } system(buf); } /* * tx_xfer() * Execute a protocol transmit */ static void tx_xfer() { char buf[80]; char fname[60]; prompt_read("Send file: ", fname, sizeof(fname)); switch (proto) { case PROTO_RX: strcpy(buf, "sx"); break; case PROTO_RY: strcpy(buf, "sy"); break; case PROTO_RZ: default: strcpy(buf, "sz"); break; } sprintf(buf, "%s %s", buf, fname); system(buf); } /* * ext_cmd() * Do an extended command. * * Figure out what they want to do, drive a protcol transfer. Return * value is 1 if you user wants to quit, 0 otherwise. */ static ext_cmd() { char c; register char c2; char *helpmsg = "Options are: <r>eceive, <s>end, <q>uit\r\n"; /* Get next char to see what they want to do */ while (read(ttyfd, &c, sizeof(c)) == 0) ; c &= 0x7F; /* Send char through literally */ if (c == CMD_CHAR) { write(rs232, &c, sizeof(c)); return(0); } /* Quit */ if (c == 'q') return(1); /* Receive? */ c2 = c; if ((c2 == 'r') || (c2 == 'R')) rx_xfer(); else if ((c2 == 's') || (c2 == 'S') || (c2 == 't') || (c2 == 'T')) tx_xfer(); else write(ttyfd, helpmsg, strlen(helpmsg)); return(0); } @//E*O*F term.c// chmod u=rw,g=,o= term.c exit 0
les@chinet.chi.il.us (Leslie Mikesell) (05/14/91)
In article <240@sos.com> osvaldo@sos.com (Osvaldo Gold) writes: >In article <677@genco.bungi.com> dls@genco.bungi.com (Dave L. Smith) writes: >>I have tried all sorts of contortions with rz/sz to make them work from >>within cu on SCO Xenix 386, with no luck. Does anyone have any ideas? >Quickly start a shell on the local system with ~!, get root permissions and > type: > > # xmodem -rb filename < /dev/tty1a > /dev/tty1a Cu forks into 2 processes, one that reads the remote tty line and writes to the controlling terminal and one that reads the terminal line and writes to the remote. Most versions leave the process reading the remote tty running during ~! or ~$ escapes so it is impossible to use any kind of file transfer protocol. If you have kermit set up for dial-out on your system you can either use it's own native protocol or shell escape and redirect to the tty as mentioned above. Les Mikesell les@chinet.chi.il.us
vandys@sequent.com (Andrew Valencia) (05/14/91)
By the way, I should add that this software is supplied "as is" without any sort of warranty. I am, of course, available for questions. Andy Valencia vandys@sequent.com
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (05/15/91)
In article <240@sos.com> osvaldo@sos.com (Osvaldo Gold) writes: >In article <677@genco.bungi.com> dls@genco.bungi.com (Dave L. Smith) writes: >>I have tried all sorts of contortions with rz/sz to make them work from >>within cu on SCO Xenix 386, with no luck. Does anyone have any ideas? >Try this. It works for me under ODT 1.1. Allow me to give my example using >xmodem since I don't remember how the rz/sz combo works. > [example deleted] Cu leaves it's receive process alive, eating some to most of data (like acks or data frames) coming to your system. Since both cu and rz/sz/whatever will both have reads up at various instants, some incoming data goes to cu, some to the xfer program. This is, of course, not good. My advice is to forget cu and try ecu or pcomm. ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me
brando@uicsl.csl.uiuc.edu (Brandon Brown) (05/15/91)
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: >In article <240@sos.com> osvaldo@sos.com (Osvaldo Gold) writes: >>In article <677@genco.bungi.com> dls@genco.bungi.com (Dave L. Smith) writes: >My advice is to forget cu and try ecu or pcomm. > xcomm2 works well also.... +-----------------------------------------------------------------------------+ | Brandon Brown | Internet: brando@uicsl.csl.uiuc.edu | | Coordinated Science Laboratory | UUCP: uiucuxc!addamax!brando!brown | | University of Illinois | CompuServe: 73040,447 | | Urbana, IL 61801 | GEnie: macbrando | +-----------------------------------------------------------------------------+
les@chinet.chi.il.us (Leslie Mikesell) (05/15/91)
In article <408@n4hgf.Mt-Park.GA.US> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: >My advice is to forget cu and try ecu or pcomm. Has anyone gotten either of these to work right under AT&T's SysVr3? Pcomm compiles OK but there is a problem with the screen positioning on the console and I'm not sure if it works with modems that don't keep carrier detect up all the time - it doesn't on a 3B2, anyway. What's the latest release/patch level for these? Les Mikesell les@chinet.chi.il.us
bill@unixland.uucp (Bill Heiser) (05/16/91)
In article <1991May15.160145.28400@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >>My advice is to forget cu and try ecu or pcomm. > >Has anyone gotten either of these to work right under AT&T's SysVr3? >Pcomm compiles OK but there is a problem with the screen positioning >on the console and I'm not sure if it works with modems that don't >keep carrier detect up all the time - it doesn't on a 3B2, anyway. I use pcomm occasionally on my Esix (sysvr3) system. It's OK, but not quite like the DOS Procomm it emulates (not nearly as snappy). I also use it to configure modems... but it's a paain because it changes register settings during the init. I guess I could set up a modem setting line without anything on it, or maybe an at Z... What do the rest of you use for easy communications with your modems for setting registers, etc? bill -- bill@unixland.uucp The Think_Tank BBS & Public Access Unix ...!uunet!think!unixland!bill ..!{uunet,bloom-beacon,esegue}!world!unixland!bill 508-655-3848 (2400) 508-651-8723 (9600-HST) 508-651-8733 (9600-PEP-V32)
richard@pegasus.com (Richard Foulk) (05/16/91)
> >Cu forks into 2 processes, one that reads the remote tty line and >writes to the controlling terminal and one that reads the terminal >line and writes to the remote. Most versions leave the process >reading the remote tty running during ~! or ~$ escapes so it is >impossible to use any kind of file transfer protocol. If you >have kermit set up for dial-out on your system you can either >use it's own native protocol or shell escape and redirect to >the tty as mentioned above. > You may have to be root to connect another process to a port that kermit already has open, to override the exclusive-open. I think I have a patch around here somewhere that enables kermit to fork other processes and connect them to the remote port without encountering that problem. Richard -- Richard Foulk richard@pegasus.com
urban@cbnewsl.att.com (john.urban) (05/16/91)
In article <1991May15.160145.28400@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <408@n4hgf.Mt-Park.GA.US> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: > >>My advice is to forget cu and try ecu or pcomm. > >Has anyone gotten either of these to work right under AT&T's SysVr3? >Pcomm compiles OK but there is a problem with the screen positioning >on the console and I'm not sure if it works with modems that don't >keep carrier detect up all the time - it doesn't on a 3B2, anyway. > Have you tried the ,M attribute in the Devices file? Ie: ACU tty00,M - 1200 hayes The ,M attribute has been around for sometime. It's used when modems have a real sense of carrier detect. You don't really want to strap carrier detect up all the time. Because if the client goes down with out signing off properly, your phone bill will go way up! Sincerely, John Ben Urban
les@chinet.chi.il.us (Leslie Mikesell) (05/16/91)
In article <1991May15.221705.26920@unixland.uucp> bill@unixland.uucp (Bill Heiser) writes: >I use pcomm occasionally on my Esix (sysvr3) system. It's OK, but >not quite like the DOS Procomm it emulates (not nearly as snappy). If you have vp/ix and are willing to give it the port (it won't co-exist with uugetty), you can just run DOS procomm or Telix. >I also use it to configure modems... but it's a paain because it >changes register settings during the init. I guess I could set up >a modem setting line without anything on it, or maybe an at Z... >What do the rest of you use for easy communications with your modems >for setting registers, etc? I modified a version of kermit to leave CLOCAL set if I used "set modem unknown". But if kermit5 ever gets released it will have "set carrier ignore" as a built-in command. (The pre-beta version is in the kermit/sw/ directory on watsun.cc.colubmia.edu. Windowing, long packets, a real script language, network support, etc. - looks pretty nice) But, I've had enough trouble with modems that I just make a special entry in Devices and Dialers so I can make cu throw the setup commands at them using the "modem-class" letter to pick the right set. This particular pair will set up an ATI 2400etc to V.42 mode with the interface locked at 4800 baud whenever I do a cu -sI4800 dummy_number. In Devices: ACU tty12,M - I4800 iati | ^modem class letter (many of these can exist for the same device) Ignore CD on open In Dialers: iati =,- "" \M\pAT&F2 OK ATE0&C1&D3&S0S0=1S7=60 OK\r ATQ1&W0 OK \EATDT\T CON \m\c You can actually do some fairly arbitrary scripting with this technique, but you do have to duplicate the Devices entry for every possible dialer script you might want to use on that device. Les Mikesell les@chinet.chi.il.us
det@nightowl.MN.ORG (Derek E. Terveer) (05/17/91)
bill@unixland.uucp (Bill Heiser) writes: >What do the rest of you use for easy communications with your modems >for setting registers, etc? > ...!uunet!think!unixland!bill ..!{uunet,bloom-beacon,esegue}!world!unixland!bill I simply "cu" to the modem with the following: nightowl$ cu ACU Systems: ACU Any SHORT192-bare 19200 Devices: SHORT192-Bare cul0 - 19200 tb+fast-Bare Dialers: tb+fast-Bare =W-, "" -- det@nightowl.mn.org
gh@s5000.UUCP (Sys Admin) (05/18/91)
In article <1991May13.221614.9030@sequent.com> vandys@sequent.com (Andrew Valencia) writes: gh>dls@genco.bungi.com (Dave L. Smith) writes: gh> gh>>I have tried all sorts of contortions with rz/sz to make them work from gh>>within cu on SCO Xenix 386, with no luck. Does anyone have any ideas? gh> gh>I wrote a simple terminal program which knew how to push out to do [xyz]modem. gh>It's a hundred lines or so; I can post it if people are interested in this gh>sort of solution. gh> gh> Andy Valencia gh> vandys@sequent.com I'm for posting it -- Thanks in advance____________________Glen_______________________________________ ______________________________Lexington__Oklahoma_______________________________ ______________________{uunet uunet.uu.net}!uokmax!s5000!gh______________________
rac@sherpa.UUCP (Roger Cornelius) (05/18/91)
In article <677@genco.bungi.com> dls@genco.bungi.com (Dave L. Smith) writes: >I have tried all sorts of contortions with rz/sz to make them work from >within cu on SCO Xenix 386, with no luck. Does anyone have any ideas? This works with a cu which supports ~+. The cu on SCO UNIX does but the XENIX one does not. From the cu manual page: ~+cmd... run cmd on the local system (via sh -c), with both standard input and standard output of cmd redirected to the remote system. -- Roger Cornelius rac@sherpa.UUCP uunet!sherpa!rac
md@sco.COM (Michael Davidson) (05/21/91)
osvaldo@sos.com (Osvaldo Gold) writes: >In article <677@genco.bungi.com> dls@genco.bungi.com (Dave L. Smith) writes: >>I have tried all sorts of contortions with rz/sz to make them work from >>within cu on SCO Xenix 386, with no luck. Does anyone have any ideas? >Try this. It works for me under ODT 1.1. Allow me to give my example using >xmodem since I don't remember how the rz/sz combo works. >Initiate the cu session to the remote system. >Start "xmodem -sb filename" at the remote system. >Quickly start a shell on the local system with ~!, get root permissions and > type: > # xmodem -rb filename < /dev/tty1a > /dev/tty1a With SCO UNIX 3.2.2 onwards there is a simpler solution to this. From 3.2.2 onwards cu supports an escape that will run a command with it's standard input and output redirected to the communications line to the remote machine rather than the local tty (which is what the ~!command escape does). The new escape is ~+command and I'm afraid it is only available in 3.2.2 onwards.
jpr@jpradley.jpr.com (Jean-Pierre Radley) (05/23/91)
In article <1991May15.151102.8516@ux1.cso.uiuc.edu> brando@uicsl.csl.uiuc.edu (Brandon Brown) writes: >wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: >>In article <240@sos.com> osvaldo@sos.com (Osvaldo Gold) writes: >>>In article <677@genco.bungi.com> dls@genco.bungi.com (Dave L. Smith) writes: > >>My advice is to forget cu and try ecu or pcomm. > >xcomm2 works well also.... Xcmalt works fine with sz/rz. What is xcomm2? Jean-Pierre Radley Unix in NYC jpr@jpr.com jpradley!jpr CIS: 72160,1341
wes@harem.clydeunix.com (Barnacle Wes) (05/31/91)
In article <1991May15.221705.26920@unixland.uucp>, bill@unixland.uucp (Bill Heiser) writes:
% I use pcomm occasionally on my Esix (sysvr3) system. It's OK, but
% not quite like the DOS Procomm it emulates (not nearly as snappy).
%
% I also use it to configure modems... but it's a paain because it
% changes register settings during the init. I guess I could set up
% a modem setting line without anything on it, or maybe an at Z...
%
% What do the rest of you use for easy communications with your modems
% for setting registers, etc?
C-kermit. It's the only software I have under unix that will let you
just connect to a port and talk to whatever is plugged in. A nice thing
to have.
Wes Peters
--
#include <std/disclaimer.h> The worst day sailing
My opinions, your screen. is much better than
Raxco had nothing to do with this! the best day at work.
Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes