Linux and SCO
Brian E. Seppanen
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
LFessen106
Use vt100 emulation instead.
Wolf Grossi
Wolf
T.E.Dickey
> 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
>
> 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
>> 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
> 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
> 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
Linus Torvalds
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
> 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
>> 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
> 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
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
Bill Vermillion
>> 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.
arch harris
> 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 |
T.E.Dickey
> 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.
not an argument (take it as you wish), but a statement of fact.
T.E.Dickey
> 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).
I agree with this (which is why I made xterm support the two styles - PC
and vt220 keyboard). Though I usually find the latter is more useful...
> 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.
All of my keyboards (I suppose it depends on where you buy equipment)
just have a "<-" label rather than "backspace" (I suppose it would
be unreasonable for me to have it transmit "<esc>[B " ;-)
-- but actually, the whole issue about BS vs DEL came about historically
based on which terminals were inexpensive around 1980.
T.E.Dickey
> 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
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
> 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
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
> 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
T.E.Dickey <dic...@shell.clark.net> wrote:
>In comp.os.linux.misc Bill Vermillion <bi...@wjv.com.removeme> wrote:
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
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