ckuker.bwr

linux终端仿真程序

  I know of one customer in Australia who is successfully using this, with
  kermit scripts, to manage some X.25-connected switches. He used standard
  kermit, compiled for Solaris 2, with X.25 8.0 xty devices.

C-Kermit can't be compiled successfully under Solaris 2.3 using SUNWspro cc
2.0.1 unless at least some of the following patches are applied to cc (it is
not known which one(s), if any, fix the problem):

  100935-01 SparcCompiler C 2.0.1: bad code generated when addresses
    of two double arguments are involved 
  100961-05 SPARCcompilers C 2.0.1: conditional expression with
    function returning strucure gives wrong value 
  100974-01 SparcWorks 2.0.1: dbx jumbo patch
  101424-01 SPARCworks 2.0.1 maketool SEGV's instantly on Solaris 2.3

With unpatched cc 2.0.1, the symptom is that certain modules generate
truncated object files, resulting in many unresolved references at link time.

Using a Sun workstation keyboard for VT emulation when accessing VMS:

From: Jerry Leichter <[e-mail]>
Newsgroups: comp.os.vms
Subject: Re: VT100 keyboard mapping to Sun X server
Date: Mon, 19 Aug 1996 12:44:21 -0400

> I am stuck right now using a Sun keyboard (type 5) on systems running SunOS
> and Solaris.  I would like to use EVE on an OpenVMS box with display back to
> the Sun.  Does anyone know of a keyboard mapping (or some other procedure)
> which will allow the Sun keyboard to approximate a VT100/VT220?

You can't get it exactly - because the keypad has one fewer key - but
you can come pretty close.  Here's a set of keydefs I use:

keycode 101=KP_0
keycode 119=KP_1
keycode 120=KP_2
keycode 121=KP_3
keycode 98=KP_4
keycode 99=KP_5
keycode 100=KP_6
keycode 75=KP_7
keycode 76=KP_8
keycode 77=KP_9
keycode 52=KP_F1
keycode 53=KP_F2
keycode 54=KP_F3
keycode 57=KP_Decimal
keycode 28=Left
keycode 29=Right
keycode 30=KP_Separator
keycode 105=KP_F4
keycode 78=KP_Subtract
keycode 8=Left
keycode 10=Right
keycode 32=Up
keycode 33=Down
keycode 97=KP_Enter

Put this in a file - I use "keydefs" in my home directory and feed it
into xmodmap:

  xmodmap - <$HOME/keydefs

This takes care of the arrow keys and the "calculator" key cluster.  The
"+" key will play the role of the DEC "," key.	The Sun "-" key will be
like the DEC "-" key, though it's in a physically different position -
where the DEC PF4 key is.  The PF4 key is ... damn, I'm not sure where
"key 105" is.  I *think* it may be on the leftmost key of the group of
four just above the "calculator" key cluster.

I also execute the following (this is all in my xinitrc file):

xmodmap -e 'keysym KP_Decimal = KP_Decimal'
xmodmap -e 'keysym BackSpace = Delete BackSpace' \
        -e 'keysym Delete = BackSpace Delete'
xmodmap -e 'keysym KP_Decimal = Delete Delete KP_Decimal'
xmodmap -e 'add mod1 = Meta_R'
xmodmap -e 'add mod1 = Meta_L'

Beware of one thing about xmodmap:  Keymap changes are applied to the
*whole workstation*, not just to individual windows.  There is, in fact,
no way I know of to apply them to individual windows.  These definitions
*may* confuse some Unix programs (and/or some Unix users).

If you're using Motif, you may also need to apply bindings at the Motif
level.  If just using xmodmap doesn't work, I can try and dig that stuff
up for you.

(end quote)

  NOTE: The rest of the problems in this section have to do with bidirectional
  tty lines and the Solaris Port Monitor.  Hopefully these are all fixed in
  C-Kermit 6.0.192 Beta.029, 22 Aug 96.

Reportedly, "C-Kermit ... causes a SPARCstation running Solaris 2.3
to panic after the modem connects.  I have tried compiling C-Kermit with Sun's
unbundled C compiler, with GCC Versions 2.4.5 and 2.5.3, with make targets
'sunos51', 'sunos51tcp', 'sunos51gcc', and even 'sys5r4', and each time it
compiles and starts up cleanly, but without fail, as soon as I dial the number
and get a 'CONNECT' message from the modem, I get:

  BAD TRAP
  kermit: Data fault
  kernel read fault at addr=0x45c, pme=0x0
  Sync Error Reg 80 <INVALID>
  ...
  panic: Data Fault.
  ...
  Rebooting...

The same modem works fine for UUCP/tip calling."  Also (reportedly), this only
happens if the dialout port is configured as in/out via admintool.  If it is
configured as out-only, no problem.  This is the same dialing code that works
on hundreds of other System-V based UNIX OS's.  Since it should be impossible
for a user program to crash the operating system, this problem must be chalked
up to a Solaris bug.  Even if you SET CARRIER OFF, CONNECT, and dial manually
by typing ATDTnnnnnnn, the system panics as soon as the modem issues its
CONNECT message.  (Clearly, when you are dialing manually, C-Kermit does not
know a thing about the CONNECT message, and so the panic is almost certainly
caused by the transition of the Carrier Detect (CD) line from off to on.)
This problem was reported by many users, all of whom say that C-Kermit worked
fine on Solaris 2.1 and 2.2.  If the speculation about CD is true, then a
possible workaround might be to configure the modem to leave CD on (or off)
all the time.  Perhaps by the time you read this, a patch will have been
issued for Solaris 2.3.

The following is from Karl S. Marsh, Systems & Networks Administrator,
AMBIX Systems Corp, Rochester, NY (begin quote):

"Environment:
  Solaris 2.3 Patch 101318-45
  C-Kermit 5A(189) (and presumably this applies to 188 and 190 also)
  eeprom setting:
    ttya-rts-dtr-off=false
    ttya-ignore-cd=false
    ttya-mode=19200,8,n,8,-

"To use C-Kermit on a bidirectional port in this environment, do not use
admintool to configure the port.  Use admintool to delete any services running
on the port and then quit admintool and issue the following command:

  pmadm -a -p zsmon -s ttyb -i root -fu -v 1 -m "`ttyadm -b -d /dev/term/b \
  -l conttyH -m ldterm,ttcompat -s /usr/bin/login -S n`"

[NOTE: This was copied from a fax, so please check it carefully]  where:

  -a = Add service
  -p = pmtag (zsmon)
  -s = service tag (ttyb)
  -i = id to be associated with service tag (root)
  -fu = create utmp entry
  -v = version of ttyadm
  -m = port monitor-specific portion of the port monitor administrative file
       entry for the service
  -b = set up port for bidirectional use
  -d = full path name of device
  -l = which ttylabel in the /etc/ttydefs file to use
  -m = a list of pushable STREAMS modules
  -s = pathname of service to be invoked when connection request received
  -S = software carrier detect on or off (n = off)

"This is exactly how I was able to get Kermit to work on a bi-directional
port without crashing the system."  (End quote)

On the Solaris problem, also see SunSolve Bug ID 1150457 ("Using C-Kermit, get
Bad Trap on receiving prompt from remote system").  Another user reported "So,
I have communicated with the Sun tech support person that submitted this bug
report [1150457].  Apparently, this bug was fixed under one of the jumbo
kernel patches.  It would seem that the fix did not live on into 101318-45, as
this is EXACTLY the error that I see when I attempt to use kermit on my
system."

Later (Aug 94)...  C-Kermit dialout successfully tested on a Sun4m with a
heavily patched Solaris 2.3.  The patches most likely to have been relevant:

101318-50: SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)
101720-01: SunOS 5.3: ttymon - prompt not always visible on a modem connection
101815-01: SunOS 5.3: Data fault in put() NULL queue passed from
                      ttycommon_qfull()
101328-01: SunOS 5.3: Automation script to properly setup tty ports prior to
                      PCTS execution

Still later (Nov 94): another user (Bo Kullmar in Sweden) reports that after
using C-Kermit to dial out on a bidirectional port, the port might not answer
subsequent incoming calls, and says "the problem is easy enough to to fix with
the Serial Port Manager; I just delete the service and and install it again
using the graphical interface, which underneath uses commands like sacadm and
pmadm."  Later Bo reports, "I have found that if I run Kermit with the
following script then it works.  This script is for /dev/cua/a, -s a is the
last a in /dev/cua/a

  #! /bin/sh
  kermit
  sleep 2
  surun pmadm -e -p zsmon -s a

(end quote)

(3.8) C-KERMIT AND SUNOS

Sun SPARCstation users should read the section "Setting up Modem Software" in
the Desktop SPARC Sun System & Network Manager's Guide.  If you don't set up
your serial ports correctly, Kermit (and other communications software) won't
work right.

Reportedly, C-Kermit does not work correctly on a Sun SPARCstation in an Open
Windows window with scrolling enabled.  Disable scrolling, or else invoke
Kermit in a terminal emulation window (xterm, crttool, vttool) under SunView
(this might be fixed in later SunOS releases).

On the Sun with Open Windows, an additional symptom has been reported:
outbound SunLink X.25 connections "magically" translate CR typed at the
keyboard into LF before transmission to the remote host.  This doesn't happen
under SunView.

SET CARRIER ON, when used on the SunOS 4.1 version of C-Kermit (compiled in
the BSD universe), causes the program to hang uninterruptibly when SET LINE
is issued for a device that is not asserting carrier.  When Kermit is built
in the Sys V universe on the same computer, there is no problem (it can be
interrupted with Ctrl-C).  This is apparently a limitation of the BSD-style
tty driver.

SunOS 4.1 C-Kermit has been observed to dump core when running a complicated
script program under cron.  The dump invariably occurs in ttoc(), while trying
to output a character to a TCP/IP TELNET connection.  ttoc() contains a
write() call, and when the system or the network is very busy, the write()
call can get stuck for long periods of time.  To break out of deadlocks caused
by stuck write() calls, there is an alarm around the write().  It is possible
that the core dump occurs when this alarm signal is caught.  (This one has
not been observed recently -- possibly fixed in edit 190.)

On Sun computers with SunOS 4.0 or 4.1, SET FLOW RTS/CTS works only if the
carrier signal is present from the communication device at the time when
C-Kermit enters packet mode or CONNECT mode.  If carrier is not sensed (e.g.
when dialing), C-Kermit does not attempt to turn on RTS/CTS flow control.
This is because the SunOS serial device driver does not allow characters to
be output if RTS/CTS is set (CRTSCTS) but carrier (and DSR) are not present.
Workaround (maybe):  SET CARRIER OFF before giving the SET LINE command,
establish the connection, then SET FLOW RTS/CTS

It has also been reported that RTS/CTS flow control under SunOS 4.1 through
4.1.3 works only on INPUT, not on output, and that there is a patch from Sun
to correct this problem: Patch-ID# T100513-04, 20 July 1993 (this patch might
apply only to SunOS 4.1.3).  It might also be necessary to configure the
eeprom parameters of the serial port; e.g. do the following as root at the
shell prompt:

  eeprom  ttya-ignore-cd=false
  eeprom  ttya-rts-dtr-off=true

There have been reports of file transfer failures on Sun-3 systems when using
long packets and/or large window sizes.  One user says that when this happens,
the console issues many copies of this message:

  chaos vmunix: zs1: ring buffer overflow

This means that SunOS is not scheduling Kermit frequently enough to service
interrupts from the zs serial device (Zilog 8350 SCC serial communication
port) before its input silo overflows.  Workaround: use smaller packets
and/or a smaller window size, or use "nice" to increase Kermit's priority.
Use hardware flow control if available, or remove other active processes
before running Kermit.

SunLink X.25 support in C-Kermit 5A(190) has been built and tested
successfully under SunOS 4.1.3b and SunLink X.25 7.00.

(3.9) C-KERMIT AND ULTRIX

There is no hardware flow control in Ultrix.  That's not a Kermit deficiency,
but an Ultrix one.

Reportedly, DEC ULTRIX 4.3 is immune to C-Kermit's disabling of SIGQUIT,
which is the signal that is generated when the user types Ctrl-\, which kills
the current process (i.e. C-Kermit) and dumps core.  Diagnosis and cure
unknown.  Workaround: before starting C-Kermit -- or for that matter, when you
first log in because this applies to all processes, not just Kermit -- give
the following UNIX command:

  stty quit undef