Linux and SCO

164 views
Skip to first unread message

Brian E. Seppanen

unread,
Apr 27, 2000, 3:00:00 AM4/27/00
to
I have a couple of SCO servers that I periodically have to log into for
administrative tasks, and I'm having a couple of problems relating to
using Linux to do these tasks.

When I log into the SCO machines, I do so in the following way:

xterm -tn scoansi -e telnet xxx.xxx.xxx.xxx
xterm -tn ansi -e telnet xxx.xxx.xxx.xxx

I fire up an Xterm and set the environment variable to what I thought was
appropriate.

What I notice when I attach to the SCO machines is that hitting backspace
does not backspace at all, in fact it puts me on a brand new command
line. In other words I have to insure I've put the command properly
otherwise I have to start from scratch, I cannot edit mistakes. Not fun
when you don't have any command history and you have to type 'ps -e -o
pcpu,comm,pid,user | grep blah' constantly.

When I try to fire up Scoadmin (A visual administration tool), I get the
following error as well.

dynamic linker : xm_vtcld : error opening libXm.so

At this point scoadmin goes to a defunct state, and I have to login on a
new session and kill the old one. Any ideas on what's causing the
problem. Has anyone gotten this to work.

I'd really appreciate any assistance.

Thanks,


Brian Seppanen
bsep...@bellmemorial.org


Wolf Grossi

unread,
Apr 27, 2000, 3:00:00 AM4/27/00
to
Try to add the path of libXm.so to LD_LIBRARY_PATH (shared objects library).
Wolf

T.E.Dickey

unread,
Apr 28, 2000, 3:00:00 AM4/28/00
to
In comp.os.linux.misc Brian E. Seppanen <bsep...@bellmemorial.org> wrote:
> When I log into the SCO machines, I do so in the following way:

> xterm -tn scoansi -e telnet xxx.xxx.xxx.xxx
> xterm -tn ansi -e telnet xxx.xxx.xxx.xxx

scoansi and ansi aren't the same as xterm (use infocmp to see).

SCO has DEL (127) set for the interrupt character.
You are probably pressing the backarrow key, which depending on your
configuration will transmit either a backspace (8) or DEL.

--
Thomas E. Dickey
dic...@clark.net
http://www.clark.net/pub/dickey

Warren Young

unread,
Apr 28, 2000, 3:00:00 AM4/28/00
to
"Brian E. Seppanen" wrote:
>
> What I notice when I attach to the SCO machines is that hitting backspace
> does not backspace at all, in fact it puts me on a brand new command
> line.

This is because most Linuxes to date have reversed the traditional
mapping of Delete and Backspace: instead of Ctrl-H, Backspace is usually
configured to send ASCII 127, which SCO systems interpret the same way
as Linux interprets Ctrl-C.

Red Hat Linux 6.2 seems to put this behavior back the way it should be;
Ritchie be praised.

Anyway, you can fix this on either end (whichever causes the least pain)
with the stty command. It's probably simplest to do it on the SCO end,
actually.

--
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

Bill Vermillion

unread,
Apr 28, 2000, 3:00:00 AM4/28/00
to
In article <3909666C...@etr-usa.com>,

Warren Young <war...@etr-usa.com> wrote:
>"Brian E. Seppanen" wrote:

>> What I notice when I attach to the SCO machines is that hitting
>> backspace does not backspace at all, in fact it puts me on a
>> brand new command line.

>This is because most Linuxes to date have reversed the traditional
>mapping of Delete and Backspace: instead of Ctrl-H, Backspace is usually
>configured to send ASCII 127, which SCO systems interpret the same way
>as Linux interprets Ctrl-C.

I guess it really depends on just exactly what you define as
traditional, does it not?

I can't seem to find my original DEC VT100 manual [too many books
here] - about 20 years old that I picked up along the way - but the
Delete/Backspace key, with shift for backspace as I recall is the
original mapping. So those Linux distributions have not reversed the
traditional method but have reverted to the traditional method.


--
Bill Vermillion bv @ wjv.com

T.E.Dickey

unread,
Apr 28, 2000, 3:00:00 AM4/28/00
to
In comp.os.linux.misc Warren Young <war...@etr-usa.com> wrote:
> This is because most Linuxes to date have reversed the traditional
> mapping of Delete and Backspace: instead of Ctrl-H, Backspace is usually
> configured to send ASCII 127, which SCO systems interpret the same way
> as Linux interprets Ctrl-C.

ASCII backspace is control/H, aka BS (127 is DEL).

Brian E. Seppanen

unread,
Apr 28, 2000, 3:00:00 AM4/28/00
to
On Thu, 27 Apr 2000, Wolf Grossi wrote:

> Try to add the path of libXm.so to LD_LIBRARY_PATH (shared objects library).
> Wolf
>

Would this need to be on the SCO server? On my linux machine libXm.so is
in /usr/X11R6/lib which is in my library search path, so my understanding
is putting it in LD_LIBRARY_PATH is overkill. If it is to be on the SCO
server: Does SCO understand the LD_LIBRARY_PATH environment variable?

/udk/usr/X/lib/WXm/libXm.so
/udk/usr/X/lib/libXm.so
/udk/usr/lib/libXm.so

Whether this is within the library path is up for debate considering I'm
no SCO guru. It doesn't have an /etc/ld.so.conf, which would indicate the
library search path on linux.

I'd appreciate any further assistance.

thanks,

Brian Seppanen
bsep...@bellmemorial.org


Bill Campbell

unread,
Apr 28, 2000, 3:00:00 AM4/28/00
to
On Fri, Apr 28, 2000 at 04:22:36AM -0600, Warren Young wrote:
>"Brian E. Seppanen" wrote:
>>
>> What I notice when I attach to the SCO machines is that hitting backspace
>> does not backspace at all, in fact it puts me on a brand new command
>> line.
>
>This is because most Linuxes to date have reversed the traditional
>mapping of Delete and Backspace: instead of Ctrl-H, Backspace is usually
>configured to send ASCII 127, which SCO systems interpret the same way
>as Linux interprets Ctrl-C.

Probably because this is the way it was done on Vaxen in the BSD colleges
and universities where Unix and Linux matured. The true DEC VTxxx terminal
have some truly strange keyboards, and the key that's where the backspace
should be sends the DEL character.

I have this in most of my .profiles
stty erase '^H' intr '^?'

I'm actually getting in the habit of pressing ctrl-H for backspace.
It's in the home key row, and doesn't shoot me in the foot the way the
backspace might (but then I'm a vi bigot who doesn't ever use arrow
or function keys either :-).

Bill
--
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Systems, Inc.
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/

``Never blame a legislative body for not doing something. When they do
nothing, that don't hurt anybody. When they do something is when they
become dangerous.''
Will Rogers

Linus Torvalds

unread,
Apr 28, 2000, 3:00:00 AM4/28/00
to
In article <iDgO4.18959$0o4.1...@iad-read.news.verio.net>,

T.E.Dickey <dic...@shell.clark.net> wrote:
>In comp.os.linux.misc Warren Young <war...@etr-usa.com> wrote:
>> This is because most Linuxes to date have reversed the traditional
>> mapping of Delete and Backspace: instead of Ctrl-H, Backspace is usually
>> configured to send ASCII 127, which SCO systems interpret the same way
>> as Linux interprets Ctrl-C.
>
>ASCII backspace is control/H, aka BS (127 is DEL).

This is an old, and totally bogus argument.

ASCII BS (the character) is indeed \010, aka character 8, aka ^H.

But that has absolutely nothing to do with the _keyboard_button_ that
often has a back arrow on it, and also often these days has the text
"Back Space" on it.

And guess what? People _expect_ it to _delete_ the preceding character.
They'd be really upset if it just backed up over it, which was the
original TTY behaviour (ie ASCII BS is truly historically just a cursor
movement - and in that sense it is truly closer to the "cursor left" key
than to the key many people know as "Backspace").

The way you did underlined text (sometimes still used) back in the age
when ASCII was invented, was to write the character, send ASCII BS, and
write a underscore. Kind of like t^H_h^H_i^h_s^h_.

The BackSpace _keyboard_button_ is something else altogether these days.

That, on vt100 terminals (which is what the Linux console and xterms
emulate), generally sends the ASCII DEL character. The key that is
marked "Delete" sends the vt100 sequence for the delete (^[[3~, I
think). It does not send the DEL character. The way to get ^H is to
press control and H at the same time.

Note that keyboard mappings are seldom the same as "ASCII mappings".
The classical example of this is CR/LF, where there is again a big key
sometimes called "Enter", and sometimes with a curved arrow, and
sometimes with both. And depending on the day of the week and the
particular terminal, that key will send either CR of LF or both.

And the "End" key usually sends _none_ of the ASCII characters ETX, EOT
or ETB ("End of TeXt", "End Of Transmission" or "End of Transmission
Block").

Also, why don't we have a "Cancel" key, even though that is what a lot
of people use "Escape" for?

It's tough, but basically the ASCII names do not match to the keyboards,
or vice versa. And using them as an argument is not very compelling.

Linus

Tony Lawrence

unread,
Apr 29, 2000, 3:00:00 AM4/29/00
to
Linus Torvalds wrote:

> T.E.Dickey <dic...@shell.clark.net> wrote:

> >ASCII backspace is control/H, aka BS (127 is DEL).
>
> This is an old, and totally bogus argument.
>
> ASCII BS (the character) is indeed \010, aka character 8, aka ^H.
>
> But that has absolutely nothing to do with the _keyboard_button_ that
> often has a back arrow on it, and also often these days has the text
> "Back Space" on it.
>
> And guess what? People _expect_ it to _delete_ the preceding character.

Yes, they do. And that's why erase is set to CTRL-H on the
SCO box I am using this very moment as I write this. On the
Linux box that sits half naked beside it awaiting
installation of tape drive and other things I need before it
can become my desktop machine, erase is, of course, CTRL-?
or 127. When I telnet from a SCO machine to a Linux
machine, resetting erase and intr is only the beginning of
what I need to do to avoid driving myself crazy.

Of course, once I switch to Linux as my deskop, the problem
will be reversed when I access customer's SCO machines from
that box. And if I happen to be at the client's site, who
knows which machine I'll be sitting at and which machines
I'll need to get to- increasingly I have more and more
clients running both SCO and Linux.

Admittedly, it's SCO's damn fault. It would have been
smarter to make the SCO console and xterms act like a vt100
as you did with Linux. But what's done is done, and it was
done a long time ago, so it's much too late now,

What I need is a terminal emulator, ideally open source, and
that has the usual ansi, vt100 and perhaps wyse emulations,
but more importantly, has both Linux and SCO console
personalities (and it would have to account for Unixware
peculiarities too, I guess). When going from SCO to Linux it
also would need to take care of those damn color issues that
leave me blindly typing purple text on a purple background.
With that, I could work comfortably cross-platform without
constantly screwing up. I'm not sure what other issues
might come up going from Linux to SCO; I guess I'll find out
as I start doing that more..

I just had a thought- I have Merge on my SCO box and Win4Lin
( http://aplawrence.com/Reviews/win4lin.html ) on Linux. I
can run one of the Windows terminal emulators- just kidding
:-)


--
Tony Lawrence (to...@aplawrence.com)
SCO/Linux articles, help, book reviews, tests,
job listings and more : http://www.pcunix.com

Bill Vermillion

unread,
Apr 29, 2000, 3:00:00 AM4/29/00
to
In article <390ADD9F...@aplawrence.com>,

Tony Lawrence <to...@aplawrence.com> wrote:
>Linus Torvalds wrote:

>> T.E.Dickey <dic...@shell.clark.net> wrote:

>> >ASCII backspace is control/H, aka BS (127 is DEL).

>> This is an old, and totally bogus argument.

>> ASCII BS (the character) is indeed \010, aka character 8, aka ^H.

>> But that has absolutely nothing to do with the _keyboard_button_ that
>> often has a back arrow on it, and also often these days has the text
>> "Back Space" on it.

>> And guess what? People _expect_ it to _delete_ the preceding
>> character.

>Yes, they do. And that's why erase is set to CTRL-H on the
>SCO box I am using this very moment as I write this. On the
>Linux box that sits half naked beside it awaiting
>installation of tape drive and other things I need before it
>can become my desktop machine, erase is, of course, CTRL-?
>or 127. When I telnet from a SCO machine to a Linux
>machine, resetting erase and intr is only the beginning of
>what I need to do to avoid driving myself crazy.

Since I don't have any Linux systems running here at the moment -
let me ask this. Does the Linux implementation accuratly
emulate the VT100 - where the <-- key is ^? and shift <--
is ^H.

So many of the terminal emulation programs I've seen (and the real
VT102 I've used - which really could be called finger muscle
builders) have shift BS as the erase. Some also have the ability
to 'flip' the behaviour.

I think it would be better to leave the VT100 emulation alone and
build an alternate emulator than to muck with the VT100 'standard'.

Tony Lawrence

unread,
Apr 29, 2000, 3:00:00 AM4/29/00
to
Bill Vermillion wrote:

> Since I don't have any Linux systems running here at the moment -
> let me ask this. Does the Linux implementation accuratly
> emulate the VT100 - where the <-- key is ^? and shift <--
> is ^H.

"The" Linux implementation? :-)

The Corel Linux machine that I happen to have up and running
this second does not distinguish twixt BackSpace and
Shift-BackSpace

Frank da Cruz

unread,
Apr 29, 2000, 3:00:00 AM4/29/00
to
In article <Fts9H...@wjv.com.removeme>,
Bill Vermillion <bi...@wjv.com.REMOVEME> wrote:
: In article <390ADD9F...@aplawrence.com>,

: Tony Lawrence <to...@aplawrence.com> wrote:
: >Linus Torvalds wrote:
: >> T.E.Dickey <dic...@shell.clark.net> wrote:
: ...
: I think it would be better to leave the VT100 emulation alone and

: build an alternate emulator than to muck with the VT100 'standard'.
:
And your wish came true. PC-based Unixes like Linux and SCO each
have their own unique console terminal definition that is definitely
not VT100, although it shares the VT100's ANSI X3.64 basis. SCO has
SCOANSI and Linux has Linux Console. Also there is AT386 used by
Interactive Unix and later (I think) Unixware. The problem with
these "emulations" is that they aren't emulations at all, since they
aren't emulating anything and there is no physical terminal (like
the VT100) to check them against. Their specifications can be hard
to come by, and even when found, incomplete and/or inaccurate.

To this day, we discover undocumented sequences used by applications
that were designed for SCOANSI, AT386, etc.

As for the Backspace/Delete controversy... This is decades old.
The best policy (by the Principle of Least Astonishment) is to treat
them the same by default, as many Unix variations now do, and use
them to erase the character left of the cursor. People who truly
need to distinguish between Rubout (127) and Backspace (8) will have
enough of a clue to be able to do so.

Those of us who still use command shells are left with the remnants
of two ancient cultures: the original Unix culture and the
once-mighty DEC culture. Remember that Unix was first developed in
the late 1960s, and predates the DEC heyday. The Unix guys picked
certain keys to do certain things. DEC picked other keys to do the
same things:
Unix DEC
Erase Character ^H ^?
Erase Line @ ^U
Interrupt Process ^? ^C

The differences might largely have been because Unix was originally
accessed from Teletypes, which (if memory serves) did not have a
proper Ctrl key, whereas DEC systems (PDP-11, PDP-10, etc) were
mainly accessed from terminals that did have a Ctrl key (LA34,
LA36, VT05, VT50, VT52, VT100, ...) (although it is also true that
early DEC systems were delivered with Teletype consoles.)

After the fall of DEC culture, most of its people were absorbed into
and influenced by Unix culture, and we began to see DEC usage
predominate. Still, many Unixes are delivered with some or all of
the default original Unix setups. The result being that when you
Telnet to different Unix systems, you never know what Ctrl-H or
Del/Rubout will do.

For that reason, terminal emulators always give you a choice for the
mapping the Backpace (<-) key.

Of course matters are even more cofusing when we throw in EMACS/Vi
conventions, Function keys, the arrow keypad, and so forth, not to
mention keys with promising labels like "Insert", "Page Up", "Find",
"Select" and "Help", but that's a different story! Wouldn't it be
great if, after all these years, keys actually did what their
keytops say they do?

- Frank

Jeff Hyman

unread,
Apr 29, 2000, 3:00:00 AM4/29/00
to

It would be nice if 'stty' would allow making
the <Del> key be programmable. I've yet to be able to do this in Linux. It
seems that BSDI, Solaris and Linux prefer the "<Ctrl> c" to abort.
Another frustration is how the 'echo' command can cause a problem
with the \c and \n issue. RedHat v6.0 and v6.1beta was OK with this.
Once v6.1 was released it required the -e flag to act like 'echo'
does on the rest of the world (including Solaris). I had to end up doing:

###-----------------------------------------------------------------
[ -z "${ECHO}" ] && { # Forces Sys V echo (/bin/echo)
[ -n "$BASH_VERSION" ] && { enable -n echo ; }
[ -n "$BASH" ] && { ECHO="/bin/echo -e" ; } || { ECHO=echo ; } ;
export ECHO ; } ;
###-----------------------------------------------------------------
# Solaris, BSDI, and Linux don't like the <DEL> key to abort.
# WARNING: This function in no way changes how the true <Del> key works.
# All it does is display either DEL or <Ctrl-c>... thats it.
rtn_or_del()
{
case ${FLAVOR} in
SOLARIS|BSDI) DEL="<Ctrl> c" ;;
LINUX) DEL="${so}Q $se" ;;
*) DEL="DELETE" ;;
esac ;
${ECHO} "\n\t Press ${v1}ENTER${v2} to continue \c"
${ECHO} "or ${v1}${DEL}${v2} to quit \c" ; read ans
case ${ans} in
q|Q) exit ;;
*) ;;
esac
} ;
###-----------------------------------------------------------------

I do not claim to be a programming guru... as I am not. In the
simplistic code I write, it would be nice to not have to jump over
hurdles that effect the most basic cosmetics at the keyboard, or have
to rewrite code around incompatabilities of a command as vital as
'echo'.

Concerning the color issue, 'setterm' on Linux seems to work
OK as does 'setcolor' on SCO.

PS: I am not complaining here at all... just adding to the thread
some issues I was forced to deal with when Linux became a player.

PPS: Linus... it is a real treat to see you here in this SCO Newsgroup.
Please hang around.

Best Regards,
Jeff Hyman
.--.
__________________________ .-. | | __________________________________
Lone Star Software Corp. | | | | .-. Email: je...@cactus.com
Cactus International, Inc. | |_| | | | Sales: (800) LONE-TAR
509 E. Ridgeville Blvd. _ |___ |_| | Support: (301) 829-1622
Mt. Airy, MD 21771 _| ~- | ___| Fax: (301) 829-1623
http://www.CACTUS.com \, _} | | http://www.LONE-TAR.com
------------------------- \( -- | | -----------------------------------


| |
Recently, Tony Lawrence wrote:
> Linus Torvalds wrote:
>
> > T.E.Dickey <dic...@shell.clark.net> wrote:
>

> > >ASCII backspace is control/H, aka BS (127 is DEL).
> >
> > This is an old, and totally bogus argument.
> >
> > ASCII BS (the character) is indeed \010, aka character 8, aka ^H.
> >
> > But that has absolutely nothing to do with the _keyboard_button_ that
> > often has a back arrow on it, and also often these days has the text
> > "Back Space" on it.
> >
> > And guess what? People _expect_ it to _delete_ the preceding character.
>
> Yes, they do. And that's why erase is set to CTRL-H on the
> SCO box I am using this very moment as I write this. On the
> Linux box that sits half naked beside it awaiting
> installation of tape drive and other things I need before it
> can become my desktop machine, erase is, of course, CTRL-?
> or 127. When I telnet from a SCO machine to a Linux
> machine, resetting erase and intr is only the beginning of
> what I need to do to avoid driving myself crazy.
>

J. L. Schilling

unread,
Apr 29, 2000, 3:00:00 AM4/29/00
to
Brian E. Seppanen (bsep...@bellmemorial.org) wrote:

: On Thu, 27 Apr 2000, Wolf Grossi wrote:

: > Try to add the path of libXm.so to LD_LIBRARY_PATH (shared objects library).

: Would this need to be on the SCO server? On my linux machine libXm.so is


: in /usr/X11R6/lib which is in my library search path, so my understanding
: is putting it in LD_LIBRARY_PATH is overkill. If it is to be on the SCO
: server: Does SCO understand the LD_LIBRARY_PATH environment variable?

: /udk/usr/X/lib/WXm/libXm.so
: /udk/usr/X/lib/libXm.so
: /udk/usr/lib/libXm.so

Yes, SCO systems understand LD_LIBRARY_PATH, but ...

These /udk libraries are only relevant if your application was built
with SCO's "UDK" development system, which scoadmin wouldn't have been.

On a SCO OpenServer 5.0.5 machine you should find libXm.so in the
normal, default place:

139$ /bin/ls -F /usr/lib/libXm.so*
/usr/lib/libXm.so@
/usr/lib/libXm.so.1.2.0@

and libraries in /usr/lib don't need to be pointed to by LD_LIBRARY_PATH.
So see if these libraries are indeed on your system.

--
Jonathan Schilling SCO, Inc. j...@sco.com

Bill Vermillion

unread,
Apr 29, 2000, 3:00:00 AM4/29/00
to
In article <390B0617...@aplawrence.com>,

Tony Lawrence <to...@aplawrence.com> wrote:
>Bill Vermillion wrote:

>> Since I don't have any Linux systems running here at the moment -
>> let me ask this. Does the Linux implementation accuratly
>> emulate the VT100 - where the <-- key is ^? and shift <--
>> is ^H.

>"The" Linux implementation? :-)

In 'the Linux' implementation I meant the one you were using,
and tested. You did see my list the other day of the 26 ?? Linux
variants, did you not?

>The Corel Linux machine that I happen to have up and running
>this second does not distinguish twixt BackSpace and
>Shift-BackSpace

Well then I'd call that broken behavior. All the terminal
emulators I've used in PC thingys talking to Unix devices obeyed
the same sequence as the original VT - where the shift gave you
backspace. I wish some of the Linux implementors would look to
specs or history instead of trying to reinvent things.

It reminds me much of the early PC days when some programs
gave you a difference between a control A and a control a.
(note upper and lower case).

Someone must have looked and said "Hm - you get a control character
by subtracting 32 from the key" Well that only works for UC
letters. Much of the PC world operated that way so maybe that's
why they used it.

I think people are afraid to ask questions at times on their way to
a solution. The problem often is that you have A solution but not
THE solution.

Reference a terminal if you are going to emulate one and note that
the control key just basically takes the top 3 bits to ground. In
software you mask that.

I shouldn't be surprised at this type of behavior - reference the
thread on the NT admin. Years ago I had a friend who was a very
popular software author and sold a lot of game programs. One day
something came up out the decimal value of a control character -
maybe it was control G. I just popped up with "7". He said
something like "How do you know that". And I explained that all
you had to do was look at the chart and you will see that they are
in value of 1 thru 26 matching the alphabet. He didn't know and he
really was a great programmer.

Maybe it's learning 'how' to do something without the 'why'.

On my keyboard here - I use a FreeBSD system as my mail/news and
firewall in front of the other machines - and my SCO happily goes
out to the Internet through this machine - my backspace
key gives ^H, my shift backspace gives ^? . I guess that's what
you get with 20 years of design behind the OS.

Geoff Johnson

unread,
May 1, 2000, 3:00:00 AM5/1/00
to
In the good old days when you could drive 8 users from a 10MHz 80286
and nice efficient terminals. There were hundreds of terminals on the
market
all supporting a plethora of cruddy escape sequences and realy nice
keyboards.
The common standard was that the back space key deleted the character to
the
left of the cursor and the delete key deleted the key under the cursor.

Then came the wonderfull vt100 which implemented the ANSI/ISO standard
escape
sequences. Every one jumped on the band wagon because the were so easy
to
understand and debug (and write terminal emulators for, which I did for
3 years).

Unfortunatly the VT100 keyboard was the biggest piece of crap ever
invented
(Bill Gates excepted).

I have spent my entire proffessional life cursing whenever I have had to
shoe
horn applications demands for usable keyboard layouts into an vt100
keyboard.

The whole world missed the point when it came to UNIX and terminals.
Curses allows any terminal to be driven. So develope GOOD terminals and
GOOD
terminfo descriptions for them. Dont write terminal bloody emulators.

The end result is that may years after the demise of the terminal
hardware business
and at the time when we have a mainframe available to execute the
terminal emulator
we are still arguing over the bloody terminal keyboard that was designed
to run poxy
DEC operating systems applications.

Ever tried to use FKEY 1 ... 5 or ESC of a real vt220.
Every DEC terminal should have been supplied with a key puller.

Frank da Cruz wrote:
>
> In article <Fts9H...@wjv.com.removeme>,
> Bill Vermillion <bi...@wjv.com.REMOVEME> wrote:

> : In article <390ADD9F...@aplawrence.com>,
> : Tony Lawrence <to...@aplawrence.com> wrote:


> : >Linus Torvalds wrote:
> : >> T.E.Dickey <dic...@shell.clark.net> wrote:

--

Geoff Johnson

Brian E. Seppanen

unread,
May 1, 2000, 3:00:00 AM5/1/00
to
On 29 Apr 2000, J. L. Schilling wrote:

> Brian E. Seppanen (bsep...@bellmemorial.org) wrote:
>
> : Would this need to be on the SCO server?
>

> Yes, SCO systems understand LD_LIBRARY_PATH, but ...
>

> On a SCO OpenServer 5.0.5 machine you should find libXm.so in the
> normal, default place:
>
> 139$ /bin/ls -F /usr/lib/libXm.so*
> /usr/lib/libXm.so@
> /usr/lib/libXm.so.1.2.0@
>

Well this is a box that's running X less, so I don't appear to have the
Motif libraries installed. Which brings me to my next question: why
would I need to Motif installed to run scoadmin? When I run it locally
on the machine the interface appears to be either curses or tcl? I only
want to run it in console mode. Is there anything I can do to make this
easier? the thought of running windows, because of a stupid emulator
makes me ill.

Thanks,

Brian Seppanen
bsep...@bellmemorial.org


arch harris

unread,
May 1, 2000, 3:00:00 AM5/1/00
to
In article <8ecroc$26o$1...@penguin.transmeta.com> you wrote:
> In article <iDgO4.18959$0o4.1...@iad-read.news.verio.net>,
> T.E.Dickey <dic...@shell.clark.net> wrote:
>>In comp.os.linux.misc Warren Young <war...@etr-usa.com> wrote:
>>> This is because most Linuxes to date have reversed the traditional
>>> mapping of Delete and Backspace: instead of Ctrl-H, Backspace is usually
>>> configured to send ASCII 127, which SCO systems interpret the same way
>>> as Linux interprets Ctrl-C.
>>

> This is an old, and totally bogus argument.
> ... stuff deleted


> And guess what? People _expect_ it to _delete_ the preceding character.

> They'd be really upset if it just backed up over it, which was the
> original TTY behaviour (ie ASCII BS is truly historically just a cursor
> movement - and in that sense it is truly closer to the "cursor left" key
> than to the key many people know as "Backspace").

> ... stuff deleted


> That, on vt100 terminals (which is what the Linux console and xterms
> emulate), generally sends the ASCII DEL character. The key that is
> marked "Delete" sends the vt100 sequence for the delete (^[[3~, I
> think). It does not send the DEL character. The way to get ^H is to
> press control and H at the same time.

> ... stuff deleted


> It's tough, but basically the ASCII names do not match to the keyboards,
> or vice versa. And using them as an argument is not very compelling.

I disagree. But first some information on VT keyboards.

A vt100 has no function keys (except
4 keys above a numeric keyboard where math operator keys are on a PC
keyboard). It has both a DELETE and BACKSPACE key which send ASCII
DELETE and BACKSPACE (this information from the VT100 Users Guide,
pages 4-5).

The emulation of DEL by BACKSPACE for
VT emulation stems more from the VT220 keyboard. It had a key
labeled with a left arrow with a X in it. The key was
approximately in the position of a PC keyboard backspace key and
sent ascii DEL. Thus for all those people whose muscle memory
would have their fingers reaching in that location for the DEL key,
VT emulators mapped the backspace key into the DEL key. The vt220
had no BACKSPACE key, the only way to get BACKSPACE on a vt220 was
with CNTRL-h. Therefore the fact that emulators took away the
BACKSPACE key was of no loss to someone used to a VT200 keyboard.
The vt220 had 20 function keys, but the first 5 had special
functions and sent no code to the attached computer.

First I see no reason to have a PC keybaord emulate a vt100 or vt220
keyboard. Far more users have used a PC keyboard in connection
with using Windows then have used a vt100 keyboard.
A PC keyboard has far greater capability than a vt220, lets use it.
For those who need vt220 or vt100 emulation, let them use
an emulator (or do the required reconfiguration).

linus says,


> And guess what? People _expect_ it to _delete_ the preceding character.

This is true, but it is not an old bogus argument to have
backspace be backspace. There are two "mappings" which occur to map
a keystroke into the "erase character" functionality.
There is the mapping from key to ascii
character. There then is also the mapping from Ascii character to
the "stty" erase functionality. The original design of UNIX included
the STTY erase functionality for just this reason. IHMO, distorting
the first mapping, instead of using the second mapping, is just plain
wrong.

It strikes me as being far more intuitive to have the key labeled BACKSPACE
send a BACKSPACE ascii character. If I want that key to result in
the "erase char" function, then (if it is not already the default)
I configure the system to map BACKSPACE to ERASE. This especially
seems to make more sense when the system is running in "raw" rather
than cooked mode.


| Dr. J. Archer Harris Dept of Computer Science |
| ar...@cs.jmu.edu MSC 4103 |
| harr...@jmu.edu James Madison University |
| (540) 568 - 2774 Harrisonburg, VA 22807 |

Darryl Krasman

unread,
May 1, 2000, 3:00:00 AM5/1/00
to

Try to clear the DISPLAY variable so scoadmin uses CHARM.
# unset DISPLAY

I believe there is and enviroment variable that can be set to tell
scoadmin to only use CHARM mode only but it escapes me at the moment.

--
Darryl
Ideal Computer Group Inc.

T.E.Dickey

unread,
May 2, 2000, 3:00:00 AM5/2/00
to
In comp.unix.sco.misc Linus Torvalds <torv...@penguin.transmeta.com> wrote:
> In article <iDgO4.18959$0o4.1...@iad-read.news.verio.net>,
> T.E.Dickey <dic...@shell.clark.net> wrote:
>>In comp.os.linux.misc Warren Young <war...@etr-usa.com> wrote:
>>> This is because most Linuxes to date have reversed the traditional
>>> mapping of Delete and Backspace: instead of Ctrl-H, Backspace is usually
>>> configured to send ASCII 127, which SCO systems interpret the same way
>>> as Linux interprets Ctrl-C.
>>
>>ASCII backspace is control/H, aka BS (127 is DEL).

> This is an old, and totally bogus argument.

not an argument (take it as you wish), but a statement of fact.

T.E.Dickey

unread,
May 2, 2000, 3:00:00 AM5/2/00
to
Geoff Johnson <g...@saki.com.au> wrote:
> In the good old days when you could drive 8 users from a 10MHz 80286
> and nice efficient terminals. There were hundreds of terminals on
> the market all supporting a plethora of cruddy escape sequences and
> realy nice keyboards. The common standard was that the back space
> key deleted the character to the left of the cursor and the delete
> key deleted the key under the cursor.

> Then came the wonderfull vt100 which implemented the ANSI/ISO
> standard escape sequences. Every one jumped on the band wagon
> because the were so easy to understand and debug (and write terminal
> emulators for, which I did for 3 years).

vt100's predate 286's by several years.

T.E.Dickey

unread,
May 2, 2000, 3:00:00 AM5/2/00
to
In comp.unix.sco.misc Bill Vermillion <bi...@wjv.com.removeme> wrote:

> Since I don't have any Linux systems running here at the moment -
> let me ask this. Does the Linux implementation accuratly
> emulate the VT100 - where the <-- key is ^? and shift <--
> is ^H.

I'm not at home either: I recall this as control/backarrow though,
rather than shift/backarrow.

Bill Vermillion

unread,
May 2, 2000, 3:00:00 AM5/2/00
to
In article <GjAP4.20195$0o4.1...@iad-read.news.verio.net>,

T.E.Dickey <dic...@shell.clark.net> wrote:
>In comp.unix.sco.misc Bill Vermillion <bi...@wjv.com.removeme> wrote:

>> Since I don't have any Linux systems running here at the moment -
>> let me ask this. Does the Linux implementation accuratly
>> emulate the VT100 - where the <-- key is ^? and shift <--
>> is ^H.

>I'm not at home either: I recall this as control/backarrow though,
>rather than shift/backarrow.

Well that would be strange mapping in a VT environment. In a
terminal environment if based on the classic hardware
implementation where the control key just forced the top 3 bits
to 0 level - if backspace ( you said back arrow - so I hope you are
talking about what is called the backspace key as opposed to the
left-arrow key - they are not the same) then if the non-shifted
BS/del key gave you ^? (0177/0x7f/127d) then the control backspace
would give you "us" (0037,0x1f,31d).

In the PC keyboard environment you can make any key map to anything
you wish (within reason) - but to have such behavior occur would
surely be against the original control key design.


D

T.E.Dickey

unread,
May 2, 2000, 3:00:00 AM5/2/00
to
In comp.unix.sco.misc Bill Vermillion <bi...@wjv.com.removeme> wrote:
> In article <GjAP4.20195$0o4.1...@iad-read.news.verio.net>,
> T.E.Dickey <dic...@shell.clark.net> wrote:

>>I'm not at home either: I recall this as control/backarrow though,
>>rather than shift/backarrow.

> Well that would be strange mapping in a VT environment. In a
> terminal environment if based on the classic hardware
> implementation where the control key just forced the top 3 bits
> to 0 level - if backspace ( you said back arrow - so I hope you are
> talking about what is called the backspace key as opposed to the

( yes ;-)

> left-arrow key - they are not the same) then if the non-shifted
> BS/del key gave you ^? (0177/0x7f/127d) then the control backspace
> would give you "us" (0037,0x1f,31d).

there are exceptions for some terminals (control/shift/6 aka control/uparrow)

Bill Vermillion

unread,
May 2, 2000, 3:00:00 AM5/2/00
to
In article <0uCP4.20219$0o4.1...@iad-read.news.verio.net>,

Actually that is control caret - up-arrow is typically associated
with a keypad/arrow controls and is usually an escape sequence
though Wyse 50's programmed the left-arrow to be Control H as well
as backspace to be control H, and that broke such things as spread
sheets which expected both keyb to generated different codes.

control ^ (aka shift 6) generates 0036/0x1e/30d/ - or 'rs'. Don't
have a manual delineating the abbreviations - but the control
shift 6 would be used in the original Xenix (as I recall - and I'm
prepared to be corrected) to kill a program and dump core. That
was one of the few ways to get out of a locked Xenix program.

OTOH I once did some work on an interactive videodisk application
where the ONLY input devices were light-pen and mouse. That surely
elminated a lot keyboard problems :-)

T.E.Dickey

unread,
May 2, 2000, 3:00:00 AM5/2/00
to
In comp.os.linux.misc Bill Vermillion <bi...@wjv.com.removeme> wrote:
> Actually that is control caret - up-arrow is typically associated

We called it up-arrow when I first encountered it in the 70's because
that was the way it printed on a DECWriter.

> with a keypad/arrow controls and is usually an escape sequence
> though Wyse 50's programmed the left-arrow to be Control H as well
> as backspace to be control H, and that broke such things as spread
> sheets which expected both keyb to generated different codes.

> control ^ (aka shift 6) generates 0036/0x1e/30d/ - or 'rs'. Don't

I mainly use it in vi (toggles between current and alternate buffers)

Bill Vermillion

unread,
May 3, 2000, 3:00:00 AM5/3/00
to
In article <GwIP4.20314$0o4.1...@iad-read.news.verio.net>,

T.E.Dickey <dic...@shell.clark.net> wrote:
>In comp.os.linux.misc Bill Vermillion <bi...@wjv.com.removeme> wrote:
^^^^^^^^^^ Hm. Hadn't notice that before I'm posting
in comp.unix.sco.misc. That's an invalid
newsgroup here. (private news feed so it's
not selected)

>> Actually that is control caret - up-arrow is typically associated

>We called it up-arrow when I first encountered it in the 70's because
>that was the way it printed on a DECWriter.

I remember those - an old Unix client had one of those as the
control terminal on an Onyx. A Z8000 based System III. But my
close encounter was more like 1985.

>
>> with a keypad/arrow controls and is usually an escape sequence
>> though Wyse 50's programmed the left-arrow to be Control H as well
>> as backspace to be control H, and that broke such things as spread
>> sheets which expected both keyb to generated different codes.
>
>> control ^ (aka shift 6) generates 0036/0x1e/30d/ - or 'rs'. Don't
>
>I mainly use it in vi (toggles between current and alternate buffers)
>
>--
>Thomas E. Dickey
>dic...@clark.net
>http://www.clark.net/pub/dickey

Frank da Cruz

unread,
May 3, 2000, 3:00:00 AM5/3/00
to
In article <FtyME...@wjv.com.removeme>,
Bill Vermillion <bi...@wjv.com.REMOVEME> wrote:
: In article <GwIP4.20314$0o4.1...@iad-read.news.verio.net>,
: T.E.Dickey <dic...@shell.clark.net> wrote:
: ...
: >> Actually that is control caret - up-arrow is typically associated

:
: >We called it up-arrow when I first encountered it in the 70's because
: >that was the way it printed on a DECWriter.
:
: I remember those - an old Unix client had one of those as the
: control terminal on an Onyx. A Z8000 based System III. But my
: close encounter was more like 1985.
:
Old-timers call caret "uparrow" because in the 1963 version of ASCII,
the glyph for code 94 was indeed an up-pointing arrow. Similarly, the
glyph for code 95 was left-pointing arrow. These were changed to caret
(circumflex) and underscore, respectively, in the 1967 version, which
also added lowercase letters. The 1967 version of ASCII is the same one
we use today; only the accompanying text has changed in later editions
of the standard. But of course, "getting the word out" is a long
process, and many devices continued to show the older glyphs for years
or decades, and the terminology persisted too. See, for example, Guy
Steele's Telnet Song ("Control-Uparrow Q", 1984).

Some of the programming languages designed in the 1963-67 era used left
arrow as the assignment operator. After the switch, underscore could be
used, but looked funny, so these languages were changed to use
two-character operators like := or <-, but for backwards compatibility
continued to accept underscore.

- Frank

Frank da Cruz

unread,
May 3, 2000, 3:00:00 AM5/3/00
to
In article <39104263...@saki.com.au>,
Geoff Johnson <g...@saki.com.au> wrote:
: T.E.Dickey wrote:
: > Geoff Johnson <g...@saki.com.au> wrote:
: > > ...
: > > Then came the wonderfull vt100 which implemented the ANSI/ISO

: > > standard escape sequences. Every one jumped on the band wagon
: > > because the were so easy to understand and debug (and write terminal
: > > emulators for, which I did for 3 years).
: >
: > vt100's predate 286's by several years.
: >
: And were still heavilly in use when MPM and Concurrent CPM allow multi
: user access to 286 System. I did not mean to imply that the 286 predates
: the VT100. It was the existing popularity of the vt100 that made it the
: emulators choice.
:
I think the VT100 first appeared in 1977, 3-4 years before the first IBM PC.

Actually there was a lot of resistence to VT100s when they first came out,
e.g. from the EMACS camp, which heaped abuse on them because of their
verbose escape sequences (such things made a difference in the 300bps modem
days), plus cutesy features like smooth scrolling, which pretty much tended
to throw nonstop Xoff's and Xon's back at the host (which, comically, would
crash DEC mainframes of the day).

VT100s were the first terminal to follow the ANSI X3.64 specification, which
provided an extensible framework for in-band terminal control languages
(escape sequence repertoires) that could be parsed by a simple finite-state
automaton, which did not have to know anything about the escape sequences
themselves. This was a great leap forward compared to other escape-sequence
regimes, which were driven by dispatch tables that had to be expanded every
time a new terminal model came out.

Using the X3.64 framework, terminals can harmlessly absorb escape sequences
they don't understand.

- Frank

Geoff Johnson

unread,
May 4, 2000, 3:00:00 AM5/4/00
to
T.E.Dickey wrote:
>
> Geoff Johnson <g...@saki.com.au> wrote:
> > In the good old days when you could drive 8 users from a 10MHz 80286
> > and nice efficient terminals. There were hundreds of terminals on
> > the market all supporting a plethora of cruddy escape sequences and
> > realy nice keyboards. The common standard was that the back space
> > key deleted the character to the left of the cursor and the delete
> > key deleted the key under the cursor.
>
> > Then came the wonderfull vt100 which implemented the ANSI/ISO
> > standard escape sequences. Every one jumped on the band wagon
> > because the were so easy to understand and debug (and write terminal
> > emulators for, which I did for 3 years).
>
> vt100's predate 286's by several years.
>
And were still heavilly in use when MPM and Concurrent CPM allow multi
user
access to 286 System. I did not mean to imply that the 286 predates the
VT100. It was the existing popularity of the vt100 that made it the
emulators choice.

--

Geoff Johnson

Geoff Johnson

unread,
May 4, 2000, 3:00:00 AM5/4/00
to
Frank da Cruz wrote:
>
> In article <39104263...@saki.com.au>,
> Geoff Johnson <g...@saki.com.au> wrote:
> : T.E.Dickey wrote:
> : > Geoff Johnson <g...@saki.com.au> wrote:
> : > > ...
> : > > Then came the wonderfull vt100 which implemented the ANSI/ISO

> : > > standard escape sequences. Every one jumped on the band wagon
> : > > because the were so easy to understand and debug (and write terminal
> : > > emulators for, which I did for 3 years).
> : >
> : > vt100's predate 286's by several years.
> : >
> : And were still heavilly in use when MPM and Concurrent CPM allow multi
> : user access to 286 System. I did not mean to imply that the 286 predates
> : the VT100. It was the existing popularity of the vt100 that made it the
> : emulators choice.
> :
> I think the VT100 first appeared in 1977, 3-4 years before the first IBM PC.
>
> Actually there was a lot of resistence to VT100s when they first came out,
> e.g. from the EMACS camp, which heaped abuse on them because of their
> verbose escape sequences (such things made a difference in the 300bps modem
> days), plus cutesy features like smooth scrolling, which pretty much tended
> to throw nonstop Xoff's and Xon's back at the host (which, comically, would
> crash DEC mainframes of the day).
>
> VT100s were the first terminal to follow the ANSI X3.64 specification, which
> provided an extensible framework for in-band terminal control languages
> (escape sequence repertoires) that could be parsed by a simple finite-state
> automaton, which did not have to know anything about the escape sequences
> themselves. This was a great leap forward compared to other escape-sequence
> regimes, which were driven by dispatch tables that had to be expanded every
> time a new terminal model came out.
>
> Using the X3.64 framework, terminals can harmlessly absorb escape sequences
> they don't understand.
>
After 3 years of adding features to a hardware terminal that emulated
the
vt100 and a thousand other odds and ends I don't believe there was a
randowm sequence of bytes it did not understand. Most of these mapped to
black characters on a black background :-)
Reply all
Reply to author
Forward
0 new messages