Old ASCII - FS GS RS etc?
Warnica
Talking about HCF in another thread, I pointe out EOU from the Jargon
File, and these were brought to my attention. Ive always wondered what
they are (well, all the control charactors, realy - only some are obvious
/ used) and I happen to be at a kbd logged in, and reading afc :)
So, what are all these things - and what were there origional uses?
--
Jeff Warnica jeff.w...@unb.ca l3...@unb.ca war...@unb.ca
From the University Of New Brunswickas really crappy NFSd fortune file:
Elevators smell different to midgets
,,,
From article <6768ko$m...@sol.sun.csd.unb.ca>, by l3...@jupiter.sun.csd.unb.ca (Warnica):
>
> So, what are all these things - and what were there origional uses?
I've attached an old posting of mine on the original ASCII control
characters:
Doug Jones
jo...@cs.uiowa.edu
- - - - - begin quote - - - - -
To understand the original intent of the ASCII control codes, you have
to think of teletypes, using paper tape, configured in a multidrop
system with relay logic used to turn on or off individual teletypes in
the bunch, and you have to remember that the designers were pretty
smart and they anticipated future developments, but they also managed
to include provisions for things that never happened. Here are the
ASCII control characters, and a few others, with comments on how they
were supposed to be used and how this relates to current popular uses:
NAME HEX/CTL USE
NULL 00 ^@ always ignored -- leader and trailer on paper tape
systems was typically made of sequences of NULLs.
SOH 01 ^A start of heading -- imagine a heading containing, for
example, the address of the recipient. You could have
relay logic that scans for SOH, then enables the print
mechanism if the following character matches this
station's address. In early documentation, this was
called start of message.
STX 02 ^B start of text -- if the heading matched, start printing
with the following character. In early documentation,
this was called end of address.
ETX 03 ^C end of text -- now is a good time to stop printing.
Your message might continue after this with a checksum
or other administrative stuff. In early documentation,
this was called end of message. The common use of
control C as a kill character stems from this -- it
indicates the end of your text addressed to some
application.
EOT 04 ^D end of transmission -- relay logic could decode this
and, if there is a tape in the tape reader, it could
begin transmitting its own message.
ENQ 05 ^E enquire -- on receiving this, local relay logic would
generate a response. In early documentation, this was
called WRU or who are you. Teletypes had programmable
response sequences that were encoded on a music box
mechanism, and it was up to the customer to break
plastic fingers off the drum to code how it responded
to an ENQ.
ACK 06 ^F acknowledge -- one possible response to ENQ. In early
documentation, this was called RU or are you.
BEL 07 ^G bell -- ring the bell in the terminal. Teletypes had
real bells where most modern terminals have beepers of
some kind. A sequence of BEL characters sent to a
teletype sounded very much like a telephone ringing.
BS 08 ^H backspace.
HT 09 ^I horizontal tab.
LF 0A ^J linefeed.
VT 0B ^K vertical tab.
FF 0C ^L formfeed -- page eject.
CR 0D ^M carrage return -- on many mechanical devices, CR was
slow. The sequence CR LF was always sent in that order
so that the linefeed could be handled while the carriage
was returning; a well adjusted Teletype could just finish
the CR in this time (0.2 seconds), and a common sign that
it was time to call the service man was that the first
letter printed after a CR LF was printed "on the fly" on
the way back to the margin.
SO 0E ^N shift out -- if you've got a two-color ribbon, shift to
the alternate color, usually red. There are obvious
extensions of this to alternate character sets.
SI 0F ^O shift in -- undo whatever SO does. For mysterious reasons
that have no apparent connection to old or modern ASCII
standards, DEC liked to use control O as a break character
to suppress teletype output.
DLE 10 ^P data link escape -- an escape character is generally a
prefix for something else. DLE was expected to be used
as a prefix on characters in the user data stream that
might otherwise be interpreted as data link control
characters, for example, flow control characters. In
some early documentation, this was called DC0 or device
control zero.
DC1 11 ^Q device control 1 -- turn on the paper tape reader.
In early documentation, this was called XON.
DC2 12 ^R device control 2 -- turn on the paper tape punch.
DC3 13 ^S device control 3 -- turn off the paper tape reader.
In early documentation, this was called XOFF, The use
of XON/XOFF (DC1/DC3) for flow control stems from their
use to control the flow of data from the paper tape
reader attached to a Teletype.
DC4 14 ^T device control 4 -- turn off the paper tape punch.
NAK 15 ^U negative acknowledge -- another possible response to ENQ.
One flow control mechanism is to use ENQ to ask if the
receiver has buffer space, and require the receiver to
respond with either ACK (yes) or NAK (no). ENQ could
also be used to enquire about whether a retransmission
is required after sending a checksum. The popular use of
control U to delete the current input line is only vaguely
grounded in this definition.
SYN 16 ^V synchronous idle -- if you're using a synchronous
transmission protocol, and you have no data to send, you
send SYN characters to keep the clocks synchronized.
The receiver should ignore these, and the transmitter may
have to insert them into the data stream once in a while.
ETB 17 ^W end of transmission block -- used when a transmission must
be broken into many blocks for some reason, for example,
to place a checksum after each block. Early documentation
called this logical end of media.
CAN 18 ^X cancel -- take that back, what I just sent you is a
mistake, ignore it.
EM 19 ^Y end of medium -- there's nothing left on this reel of
(paper) tape.
SUB 1A ^Z substitute -- the next character is from an alternate
character set. SUB X might be equivalent to SO X SI,
or it might be an alternate mechanism for extending the
character set. The common use of control Z as an end
of file character has no obvious relation to the standard.
ESC 1B ^[ escape -- the next character is to be interpreted as
something other than text, for example, it might be an
extended control character of some kind.
FS 1C ^\ file separator -- useful if you have multiple logical
files in one transmission.
GS 1D ^] group separator -- useful if files are made of groups
of records.
RS 1E ^^ record separator -- COBOL anyone?
US 1F ^_ unit separator -- are records made of units?
ALT 7D } Some early teletypes had an ALT MODE key that generated
this code instead of ESC. This was interpreted as an
escape code, which was no problem when nobody had lower
case printers, but with the advent of full 96 character
ASCII, there were obvious compatability problems.
PRE 7E ~ A few terminals had a PREFIX key that generated this code
instead of ALT MODE, with all the same problems.
DEL 7F delete -- remember, paper tape uses a hole to record each
one and no hole to record each zero. DEL is all holes,
so it can be punched over any other character to rub it
out (on old teletypes, it was the RUB or RUB OUT key).
If you mispunch a character, just back up the tape and
overpunch it with a DEL. Software is expected to ignore
DEL the same way it ignores NULL.
Here's the ASCII 7 bit code:
Most significant 3 bits
0 1 2 3 4 5 6 7
0 NUL DLE SP 0 @ P ` p
1 SOH DC1 ! 1 A Q a q
2 STX DC2 " 2 B R b r
3 ETX DC3 # 3 C S c s
4 EOT DC4 $ r D T d t
5 ENQ NAK % 5 E U e u
Least 6 ACK SYN & 6 F V f v
Significant 7 BEL ETB ' 7 G W g w
4 bits 8 BS CAN ( 8 H X h x
9 HT EM ) 9 I Y i y
A LF SUB * : J Z j z
B VT ESC + ; K [ k {
C FF FS , < L \ l |
D CR GS - = M ] m }
E SO RS . > N ^ n ~
F SI US / ? O _ o DEL
Marco S Hyman
l3...@jupiter.sun.csd.unb.ca (Warnica) writes:
> So, what are all these things - and what were there origional uses?
ITU-T (nee CCITT) recomendation V.3 International Alphabet No. 5 (1972) says:
IS - Information Separators
Control characters that are used to separate and qualify data
logically. There are four such characters. They may be used
either in hierarchical order or non-hierarchically; in the
latter case their specific meanings depend on their applications.
When they are used hierarchically, the ascending sequence is:
US, RS, GS, FS
In this case data normally delimited by a particular separator
cannot be split by a higher order separator but will be considered
as delimted by any higher order separator.
ANSI X3.4-1977 "code for information interchange" says:
These information separators may be used with data in optional
fasion, except that their hierarchical relationship shall be:
FS as the most inclusive, then GS, then RS, and US as the least
inclusive. (The content and length of a file, group, record, or
unit are not specified.)
// marc
J. Chris Hausler
Warnica <l3...@jupiter.sun.csd.unb.ca> writes:
>Talking about HCF in another thread, I pointe out EOU from the Jargon
>File, and these were brought to my attention. Ive always wondered what
>they are (well, all the control charactors, realy - only some are obvious
>/ used) and I happen to be at a kbd logged in, and reading afc :)
>
Record Separator. As to actual uses, a now sort of obsolete OS
that I still occasionally use, QNX 2, used RS for just that! If
you dida hex dump of a text file, each line of text was terminated
with an RS character code.
Chris
jsa...@freenet.edmonton.ab.ca
Warnica (l3...@jupiter.sun.csd.unb.ca) wrote:
: Ive always wondered what
: they are (well, all the control charactors, realy - only some are obvious
: / used) and I happen to be at a kbd logged in, and reading afc :)
In "Old" ASCII, before lowercase letters were added, FS, GS, RS weren't
present: instead, the last eight control characters were S0 through S7.
The now printable character } was ALT MODE, and I believe that | was ESC.
FS stands for "Field Separator", and the others are Group, Record, and
Unit separator. Theoretically, they could be used to perform functions
that are usually NOT performed by characters. The boundaries between
fields are usually indicated by the header of a database file, and CR is
usually used to separate records in text files.
John Savard
Nick S Bensema
In article <6769jq$nf2$1...@flood.weeg.uiowa.edu>,
,,, <jo...@pyrite.cs.uiowa.edu> wrote:
>From article <6768ko$m...@sol.sun.csd.unb.ca>, by l3...@jupiter.sun.csd.unb.ca (Warnica):
>>
>> So, what are all these things - and what were there origional uses?
>
>I've attached an old posting of mine on the original ASCII control
>characters:
I've encountered many of these in real life.
> SOH 01 ^A start of heading -- imagine a heading containing, for
> example, the address of the recipient. You could have
> relay logic that scans for SOH, then enables the print
> mechanism if the following character matches this
> station's address. In early documentation, this was
> called start of message.
Mailbox files in unix use a series of ^A's to delimit messages today.
> EOT 04 ^D end of transmission -- relay logic could decode this
> and, if there is a tape in the tape reader, it could
> begin transmitting its own message.
This is recognized as EOF on my terminal.
> ENQ 05 ^E enquire -- on receiving this, local relay logic would
> generate a response. In early documentation, this was
> called WRU or who are you. Teletypes had programmable
> response sequences that were encoded on a music box
> mechanism, and it was up to the customer to break
> plastic fingers off the drum to code how it responded
> to an ENQ.
On old TBBS systems, this character would be sent after the name prompt.
On cheap Commodore 64 terminal programs, the cursor would turn white at
this point.
By the way, many Commodore 64 terminal programs not only recognized the
bell (^G), but they made a huge gong sound for the ^V (SYN).
> ACK 06 ^F acknowledge -- one possible response to ENQ. In early
> documentation, this was called RU or are you.
Used in XMODEM. Same with NAK and CAN, probably a few others.
> SO 0E ^N shift out -- if you've got a two-color ribbon, shift to
> the alternate color, usually red. There are obvious
> extensions of this to alternate character sets.
>
> SI 0F ^O shift in -- undo whatever SO does. For mysterious reasons
> that have no apparent connection to old or modern ASCII
> standards, DEC liked to use control O as a break character
> to suppress teletype output.
^N and ^O shifted in and out of the red ribbon on my friend's old plotter
for the Vic-20. Most Commodore printers, I believe, use this to make
text wider.
> CAN 18 ^X cancel -- take that back, what I just sent you is a
> mistake, ignore it.
On BBSes, this was used to erase lines of text, rather than ^U. Sometimes
you could use either one.
--
Nick Bensema <ni...@primenet.com> 98-KUPD Red Card #710563 UIN: 2135445
~~~~ ~~~~~~~ ~~~~~~~~~~~~~~~~~~~~ Prepare ship for ludicruos speed!
http://www.climatefacts.org/ - Everyone but the bad boys have to behave.
Peter Seebach
In article <67ac90$3...@nntp02.primenet.com>,
Nick S Bensema <ni...@primenet.com> wrote:
>> SOH 01 ^A start of heading -- imagine a heading containing, for
>> example, the address of the recipient. You could have
>> relay logic that scans for SOH, then enables the print
>> mechanism if the following character matches this
>> station's address. In early documentation, this was
>> called start of message.
>Mailbox files in unix use a series of ^A's to delimit messages today.
No.
MMDF mailboxes use ^A^A^A^A. No one else does.
I've actually run into these when doing data conversion, of the form
"we have this tape, can you find out what the record format is"?
The big secret: /usr/games/factor, which I can use to get a quick guess
at what blocksizes are likely. That, and ^A/^B, sprinkled liberally.
-s
--
se...@plethora.net -- I am not speaking for my employer. Copyright '97
All rights reserved. This was not sent by my cat. C and Unix wizard -
send mail for help, or send money for a consultation. Visit my new ISP
<URL:http://www.plethora.net/> --- More Net, Less Spam! Plethora . Net
Jim Haynes
Also on some of the Teletypes (33 and 35) when used with Bell System modems
receipt of ctrl-D (EOT) would cause the modem to go on-hook. Obviously that
'feature' was removed by the time ctrl-D came to be commonly used in Unix.
Tom Watson
In article <67c6kr$c...@darkstar.ucsc.edu>, hay...@cats.ucsc.edu (Jim
Haynes) wrote:
Not necessarly true.
This "feature" only applied to a control-D processed by the printing
mechanisim. If it never got there, it didn't disconnect.
Most I/O on Unix terminals is FULL duplex, and one can type control-D INTO
the processor to their hearts content. It just never gets echoed back to
the terminal (where it will disconnect).
Model 37 (150 bps) terminals were the first to use both upper and lower
case letters (a full 96 character ASCII set), and according to the
documentation were commonly used as terminals for Unix (probably even
today, somewhere). If they were connected thru modems (probably using
Bell 103's) at Bell Labs, which I can only assume was done, the standard
"stunt box" disconnected them upon receipt of a control-D.
Early timesharing systems (of the 1960's) were both "full duplex"
(Tymshare) and "half duplex" (GE, SBC). One learned the
ddiiffffeerreennccee very quickly and knew where the 'full/half' switch
was located. Control characters were rarely used on half duplex systems
(other than cr, lf).
You are correct in that this "feature" was optional, and could be
"disabled" (usually with extreme preducice). It was mostly on TWX
terminals that were used as I/O devices, thus the feature.
ObFolklore: Have you ever used a computer by dialing a TWX number??
--
t...@cagent.com (Home: t...@johana.com)
Please forward spam to: anna...@hr.house.gov (my Congressman), I do.
The Bakers
Tom Watson wrote:
> ObFolklore: Have you ever used a computer by dialing a TWX number??
Yes, the Western Union Infomaster system. (I think this is what you were looking
for :-)
M. Baker
mba...@monmouth.com
Greg Berigan
ni...@primenet.com (Nick S Bensema) wrote:
>,,, <jo...@pyrite.cs.uiowa.edu> wrote:
>>l3...@jupiter.sun.csd.unb.ca (Warnica) wrote:
>>> So, what are all these things - and what were there origional uses?
>> I've attached an old posting of mine on the original ASCII control
>> characters:
>>
>> SO 0E ^N shift out -- if you've got a two-color ribbon, shift to
>> the alternate color, usually red. There are obvious
>> extensions of this to alternate character sets.
>>
>> SI 0F ^O shift in -- undo whatever SO does. For mysterious reasons
>> that have no apparent connection to old or modern ASCII
>> standards, DEC liked to use control O as a break character
>> to suppress teletype output.
> ^N and ^O shifted in and out of the red ribbon on my friend's old plotter
> for the Vic-20. Most Commodore printers, I believe, use this to make
> text wider.
On the program ProTERM for Apple II computers, ^O was used to turn on
inverse text. ^N restored it to normal text. ProTERM Special Emulation
still lives in the Mac version of ProTERM.
This behavior of ^O and ^N was also implemented in the 80 column firmware
for all IIs.
VT-100 would use ^N to switch to an alternate character set for lowercase
letters and some symbols and ^O would restore it. You wouldn't want to
read a message designed for viewing by ProTERM with a VT-100 nor vice
versa (if the VT-100 file used the alternate character set for line
drawing characters).
PTSE was mainly used for drawing ASCII art using Apple II MouseText
characters, enabled with ^P (firmware enabled it with ESC SI, disabled
with CAN SO -- heh, didn't realize that before). Of course, for these you
had to have an enhanced //e (65c02 processor and updated character ROMs
and CD and EF ROMs) or newer. Apple IIgs had different MouseText
characters for letters F and G (inverse carriage return symbol and racing
stripes for window bars in IIgs, combined to form a running human figure
in the //e, don't know about the //c or //c+).
--
_-<#)-=# http://cse.unl.edu/~gberigan/War-of-the-Worlds/
___/___
_-~_--<###) Due to widespread abuse, I no longer read any messages
<~c>' __--< from users who employ munged addresses in their headers.
\_--=____#) "We've upped our standards, so up yours." -- Pat Paulsen '88
Joe Morris
t...@cagent.com (Tom Watson) writes:
>In article <67c6kr$c...@darkstar.ucsc.edu>, hay...@cats.ucsc.edu (Jim
>Haynes) wrote:
>> Also on some of the Teletypes (33 and 35) when used with Bell System modems
>> receipt of ctrl-D (EOT) would cause the modem to go on-hook. Obviously that
>> 'feature' was removed by the time ctrl-D came to be commonly used in Unix.
>Not necessarly true.
>This "feature" only applied to a control-D processed by the printing
>mechanisim. If it never got there, it didn't disconnect.
[...]
>Model 37 (150 bps) terminals were the first to use both upper and lower
>case letters (a full 96 character ASCII set), and according to the
>documentation were commonly used as terminals for Unix (probably even
>today, somewhere). If they were connected thru modems (probably using
>Bell 103's) at Bell Labs, which I can only assume was done, the standard
>"stunt box" disconnected them upon receipt of a control-D.
I had only occasional contact with the TTY37 (I do recall drooling over
it when it was first introduced) but I did have a lot of logged time with
the TTY 33/35...and I think you're probably thinking of the Data Set 109,
not 103. The standard TeleType configured with an RS232 interface didn't
have any mechanism that I recall that would allow you to deassert the
DTR line (which would cause an attached modem to go on-hook), but if
you ordered it with the integrated Data Set 109 the stunt box could
send an on-hook order to the modem.
(I no longer have my TTY schematic books; I think my memory is
correct but I won't offer any double-your-money-back warranty...)
The easiest way to identify TTY33 units with an integral Data Set 109
was to look at the panel to the right of the printer/keyboard: if it
had a dial (or TouchTone button pad) and illuminated push buttons at
the bottom a 109 was installed; if there was a 3-position rotary switch
on the right side of the front panel, there was no modem installed (or
at least not one from WECo).
>Early timesharing systems (of the 1960's) were both "full duplex"
>(Tymshare) and "half duplex" (GE, SBC). One learned the
>ddiiffffeerreennccee very quickly and knew where the 'full/half' switch
>was located.
One also learned the very quickly when the switch should have been set
to HDX but was still in the FDX position...a wonderful way to thoroughly
confuse a new secretary.
ObTriviaContest: under what conditions might a user at a TTY terminal
expect to receive a line looking something like the following (with
<cr> representing a carriage return character):
XXXXXXXX<cr>OOOOOOOO<cr>********<cr>
and what technological advancement in terminal design made it impossible
to use this line for its intended purpose?
>ObFolklore: Have you ever used a computer by dialing a TWX number??
No, but if you wanted to do so you would have had an interesting time
unless you had the right modem. TWX and normal (DDD) communications
used opposite mark/space tones; the Data Set 103A1 (used with TWX
nodes) used 1070/2025 Hz (originate/answer) for mark and 1270/2225
for space; the 103A2 (for normal dialup usage) used the 1270/2225
for mark and 1070/2025 for space. The 103A2 specs became the industry
standard for computer dialup access for speeds up to 150 baud (and
later 300 as well).
Joe Morris
Heinz W. Wiggeshoff
Joe Morris (jcmo...@mwunix.mitre.org) writes:
>
> ObTriviaContest: under what conditions might a user at a TTY terminal
> expect to receive a line looking something like the following (with
> <cr> representing a carriage return character):
>
> XXXXXXXX<cr>OOOOOOOO<cr>********<cr>
>
Hardcopy password protect.
> and what technological advancement in terminal design made it impossible
> to use this line for its intended purpose?
Glass.
,,,
From article <67dvq0$m...@top.mitre.org>,
by jcmo...@mwunix.mitre.org (Joe Morris):
>
> ObTriviaContest: under what conditions might a user at a TTY terminal
> expect to receive a line looking something like the following (with
> <cr> representing a carriage return character):
>
> XXXXXXXX<cr>OOOOOOOO<cr>********<cr>
>
> to use this line for its intended purpose?
Printing this caused X, O and * to overprint in each of 8 places, making
any additional overprinting illegible. You'd output this gack first before
allowing users to type passwords, and this made it safe to carelessly
discard the printout of the password.
On half-duplex systems, this was the only way to protect passwords. On
full-duplex systems, you simply didn't bother to echo the password, or
you echoed nulls (to make the print mechanism rattle giving feedback)
or you echoed X's, to give more solid feedback.
Dumb terminals (glass teletypes) can't overprint.
Sadly, now that hardly anybody uses dumb terminals, and we're allmost
all using bitmapped display hardware, we still can't overprint. It's not
a matter of being technically difficult, but rather, the 20 year reign
of dumb terminal (or dumb graphics adapter on a PC) technology has killed
the habit!
Doug Jones
jo...@cs.uiowa.edu
Tom Watson
In article <3499F579...@monmouth.com>, The Bakers
<mba...@monmouth.com> wrote:
> Tom Watson wrote:
>
> > ObFolklore: Have you ever used a computer by dialing a TWX number??
>
> Yes, the Western Union Infomaster system. (I think this is what you
were looking
> for :-)
>
Nope. I (in my wonderful youth) used both Tymshare & GE on a TWX terminal
and called TWX numbers. I think this pre-dates infomaster by quite a few
years.
That was when AT&T had a Bell System, and TWX service was handled by
AT&T. The 'problem' was that you couldn't make a 'call' from a TWX line
to a 'DDD' line, as they were different systems. They did have area codes
(always dialed) that were (at the time, not now) distinct. They used 910,
810, 710 for west, midwest, east parts of the country, 610 for Canada, and
510 for 'rural' areas. These were 'recovered' and used as normal area
codes (510 is now Oakland CA).
I still remember the TWX number for Tymshare (the #1 940 in Palo Alto),
but since it is probably a real number somewhere, I don't think that
publishing it would be in the best interest of anyone.
ObTrivia: The GE system used the answerback as part of its 'security'.
Charlie Gibbs
In article <67c6kr$c...@darkstar.ucsc.edu> hay...@cats.ucsc.edu
(Jim Haynes) writes:
>Also on some of the Teletypes (33 and 35) when used with Bell System
>modems receipt of ctrl-D (EOT) would cause the modem to go on-hook.
>Obviously that 'feature' was removed by the time ctrl-D came to be
>commonly used in Unix.
Most of the time, when I type control-D while I'm dialed into a Unix
system, it disconnects. I guess the feature is redundant. :-)
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
Boris Gjenero
> Sadly, now that hardly anybody uses dumb terminals, and we're allmost
> all using bitmapped display hardware, we still can't overprint. It's not
> a matter of being technically difficult, but rather, the 20 year reign
> of dumb terminal (or dumb graphics adapter on a PC) technology has killed
> the habit!
> Doug Jones
> jo...@cs.uiowa.edu
xterm in Tek mode will happily overprint. However, I don't have a
decent termcap entry for that, so I never use it. Besides, I am not
even sure that termcap is flexible enough to support it or even that the
terminal is flexible enough. Isn't the terminal actually a storage CRT?
(once "drawn", pixels are on until the screen is cleared.)
--
| Boris Gjenero <bgje...@undergrad.math.uwaterloo.ca> |
| Home page: http://www.undergrad.math.uwaterloo.ca/~bgjenero/ |
| "Luke, you're going to find that many of the truths we cling to |
| depend greatly on our own point of view." - Obi-Wan Kenobi, ROTJ |
DoN. Nichols
In article <349AB015...@undergrad.math.uwaterloo.ca>,
Boris Gjenero <bgje...@undergrad.math.uwaterloo.ca> wrote:
>> Sadly, now that hardly anybody uses dumb terminals, and we're allmost
>> all using bitmapped display hardware, we still can't overprint. It's not
>> a matter of being technically difficult, but rather, the 20 year reign
>> of dumb terminal (or dumb graphics adapter on a PC) technology has killed
>> the habit!
>> Doug Jones
>> jo...@cs.uiowa.edu
>
>xterm in Tek mode will happily overprint. However, I don't have a
>decent termcap entry for that, so I never use it. Besides, I am not
>even sure that termcap is flexible enough to support it or even that the
>terminal is flexible enough. Isn't the terminal actually a storage CRT?
>(once "drawn", pixels are on until the screen is cleared.)
The Tek terminals (4010, 4012, 4014, etc) did use a storage CRT, and
as a result, this overprint approach to password security would work quite
well.
The last time I tried a 4012 on a unix box, the termcap was smart
enough to wait for the screen to erace (it took a second or two) before
continuing with the next screen.
However, it was not smart enough to work properly with the
work-around which the Tek used to get around not being able to scroll. It
assumed that typical lines were less than 40 characters wide, and would move
the cursor from the CR/LF at the end of the last line to a new position at
the top of the screen at column 40. This gave you twice as many lines -- as
long as you didn't need to deal with long lines. (And given the delay
involved in blanking the screen, it was an advantage.)
O.K. -- I just checked, and the xterm Tek mode does not only
overprint, but it does it properly -- remembering all the pixels which were
already turned on. I'd never thought to check for that, before.
Enjoy,
DoN.
--
NOTE: spamblocking on against servers which harbor spammers.
Email: <dnic...@d-and-d.com> | Donald Nichols (DoN.)|Voice (703) 938-4564
My Concertina web page: | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
DoN. Nichols
In article <544.292T2...@sky.bus.com>,
Charlie Gibbs <cgi...@sky.bus.com> wrote:
>In article <67c6kr$c...@darkstar.ucsc.edu> hay...@cats.ucsc.edu
>(Jim Haynes) writes:
>
>>Also on some of the Teletypes (33 and 35) when used with Bell System
>>modems receipt of ctrl-D (EOT) would cause the modem to go on-hook.
>>Obviously that 'feature' was removed by the time ctrl-D came to be
>>commonly used in Unix.
>
>Most of the time, when I type control-D while I'm dialed into a Unix
>system, it disconnects. I guess the feature is redundant. :-)
It disconnects if you're in your login shell -- because you just
told it to. '^-D' is the generic EOF marker on any data stream, including
that from the terminal to the shell. Some shells, such as tcsh, which I'm
currently using, allow you to use '^D' to exit from all the deeper layers,
but protects you from ending your login session without explicitly typing
'exit'. This protection may be configured to be present or not. The option
to set is "ignoreeof".
Warnica
: On old TBBS systems, this character would be sent after the name prompt.
: On cheap Commodore 64 terminal programs, the cursor would turn white at
: this point.
: By the way, many Commodore 64 terminal programs not only recognized the
: bell (^G), but they made a huge gong sound for the ^V (SYN).
I loved the gong sound, and to this day long for it in the real world.
Commodore users definitly had the best (hobby) communication stuff. With
the (possible) exception of Renegade, C= BBS's prgs killed IBM things.
Image BBS is better than even Wildcat.
But then agian, hanging a modem off a PC generaly dosent kill the stock PS
:)
--
Jeff Warnica jeff.w...@unb.ca l3...@unb.ca war...@unb.ca
From the University Of New Brunswickas really crappy NFSd fortune file:
"If the King's English was good enough for Jesus, it's good enough for
me!"
-- "Ma" Ferguson, Governor of Texas (circa 1920)
Nick S Bensema
In article <67guk4$5...@sol.sun.csd.unb.ca>,
Warnica <l3...@jupiter.sun.csd.unb.ca> wrote:
>
>I loved the gong sound, and to this day long for it in the real world.
>Commodore users definitly had the best (hobby) communication stuff. With
>the (possible) exception of Renegade, C= BBS's prgs killed IBM things.
>Image BBS is better than even Wildcat.
Image is better for sure, though slower. Had it been faster, people would
have purchased C64s just to run BBSes with.
Commodore 64 BBSes were unmatched in colorfulness. Even the most benign
of prompts could look like ti was on fire for no reason, or look like
a spcaeship, or whatever. They had SO much style. Especially the
warez boards. It's much owed to the fact that just about every function
was a single keystroke, maybe with a qualifier, and just about everything
was diagrammed on the keyboard, like colors and graphics characters and
stuff. No Alt-0223's or ESC [9m stuff that you have to go look up.
That's why I never got into ANSI graphics despite a few years of doing
graphics for several BBSes.
And many of them were written in BASIC, so anyone could modify it without
causing segmentation faults or recompiling or whatnot. I never ran a BBS,
but I was responsible for "beaming macros". You know how those little
taglines came up before the menu on Color64 boards, and on some systems
they scrolled in from the left, and on others they were all random
colors? Well I made one that would generate a little platform and the
letters would beam in. It even checked for 300 baud users and just
did them normally if it'd take too long, if I recall. Don't know if
this made it outside Arizona though.
Back to the original thread, though... I bet VT220 or VT300 or whatever
the latest DEC emulation from hell is, has ten-character escape codes
for many of the functions designed into the upper 0x20 of ASCII.
Anyone know for sure?
Nick S Bensema
In article <67dvq0$m...@top.mitre.org>,
Joe Morris <jcmo...@mwunix.mitre.org> wrote:
>
>ObTriviaContest: under what conditions might a user at a TTY terminal
>expect to receive a line looking something like the following (with
><cr> representing a carriage return character):
>
>XXXXXXXX<cr>OOOOOOOO<cr>********<cr>
>
>and what technological advancement in terminal design made it impossible
>to use this line for its intended purpose?
I read about this once in one of those phracker magazines. I think, oddly
enough, it had something to do with hacking McDonald's.
Basically, since there's no linefeeds, it would type the O's over the X's,
and the asterisks over the O-X hybrids, creating more or less solid blocks.
The file I read claimed that they used HHHHHHHH^MIIIIIIII^MXXXXXXXX.
This was useful for half-duplex connections where a confidential password
had to be typed without any written record of it. The file I read stated
that the HIX method left four pixels clear, and you would determine the
letters, sort of, by which pixels were eventually set by typing in the
password.
Gregory Travis
In article <67fl48$1...@izalco.d-and-d.com>,
DoN. Nichols <dnic...@d-and-d.com> wrote:
> It disconnects if you're in your login shell -- because you just
>told it to. '^-D' is the generic EOF marker on any data stream, including
>that from the terminal to the shell. Some shells, such as tcsh, which I'm
>currently using, allow you to use '^D' to exit from all the deeper layers,
>but protects you from ending your login session without explicitly typing
>'exit'. This protection may be configured to be present or not. The option
>to set is "ignoreeof".
^D is only the EOF marker (unless reset to another character) for the
tty data stream. A ^D in a file, over a socket, etc. will not cause
read(2) to return EOF. Only when the file descriptor passed to read(2)
is a tty and only when that tty is in cooked mode will a ^D get
translated to an EOF.
greg
Juergen Nickelsen
DoN. Nichols <dnic...@d-and-d.com> wrote:
[Ctrl-D and the Unix shells]
> It disconnects if you're in your login shell -- because you just
> told it to. '^-D' is the generic EOF marker on any data stream, including
> that from the terminal to the shell.
Ctrl-D is the EOF character on data streams coming from the *terminal*.
The TTY driver interprets this as EOF. Unix has no generic EOF marker; a
process recognizes EOF on a data stream when the read(2) system call
returns zero bytes. And this is what the TTY driver does: When it has
read a Ctrl-D from the terminal, it returns zero bytes to the next
read(2) call for this stream.
Real EOF markers were in use for text files under CP/M. Because the
exact length of a file was not stored on the disk (only the number of
blocks used), the end of the text file was marked by a Ctrl-Z. (For
binary files the exact length was considered irrelevant if you did not
know it already. Main thing is you read all the blocks.)
There was a 16-bit CP/M clone called MS-DOS which in a way mimicked this
behaviour. The weird thing was that because (at least in releases >= 2)
the exact length of a text file *was* known (i.e. stored on the disk) an
EOF marker was not necessary. Nevertheless in some situations a Ctrl-Z
was treated as an EOF marker, e.g. when copying a file to the printer.
You had to switch on "binary mode" first in order to be able to transfer
the Ctrl-Z character. When copying the same file on the disk, however,
binary mode was the default.
--
Juergen Nickelsen
J. Chris Hausler
Gregory Travis <gr...@sherrill.kiva.net> writes:
>^D is only the EOF marker (unless reset to another character) for the
Chris
Joe Morris
It's "End of _Transmission_". In the switched-message world this was
the character used to indicate that no more text should be expected
from the originating station and that the connection between the
originating and receiving stations could be dropped.
Presumably this interpretation and its implementation in the stunt
boxes inside various TTY machines were the reason for its conscription
as the end-of-file token in the UNIX world.
Of course, EOT could (and did) have other uses in nonswitched (polled)
systems, and I've always been slightly amused at the (necessary) hacks
used to transmit the EOT bit pattern as a data byte in synchronous data
circuits where it would normally be interpreted it as a control character.
Joe Morris
Charlie Gibbs
In article <67il5s$k...@nntp02.primenet.com> ni...@primenet.com (Nick S
Bensema) writes:
>Basically, since there's no linefeeds, it would type the O's over
>the X's, and the asterisks over the O-X hybrids, creating more or
>less solid blocks. The file I read claimed that they used
>HHHHHHHH^MIIIIIIII^MXXXXXXXX.
>
>This was useful for half-duplex connections where a confidential
>password had to be typed without any written record of it. The
>file I read stated that the HIX method left four pixels clear,
>and you would determine the letters, sort of, by which pixels
>were eventually set by typing in the password.
Back in my university days, the perferred terminal was the IBM 2741,
which used the Selectric mechanism. There were also a number of
Teletype terminals. Since these all used fully-formed characters
instead of a dot matrix, presumably the most effective pattern
was different. The pattern used on these terminals was WMBI,
which left a very dense black block.
John Scott McCauley Jr
>
> It disconnects if you're in your login shell -- because you just
>told it to. '^-D' is the generic EOF marker on any data stream, including
>currently using, allow you to use '^D' to exit from all the deeper layers,
>but protects you from ending your login session without explicitly typing
>'exit'. This protection may be configured to be present or not. The option
>to set is "ignoreeof".
>
Try typing 25 or so ^D's in a row to a tcsh with ignoreeof set.
Scott
jsa...@freenet.edmonton.ab.ca
Joe Morris <jcmo...@mwunix.mitre.org> wrote:
>ObTriviaContest: under what conditions might a user at a TTY terminal
>expect to receive a line looking something like the following (with
><cr> representing a carriage return character):
>XXXXXXXX<cr>OOOOOOOO<cr>********<cr>
>and what technological advancement in terminal design made it impossible
>to use this line for its intended purpose?
The answer is that when terminals changed from printing on paper to being
CRT terminals, <cr> or <lf> by itself tended to be chosen as the new line
character, since CRT terminals normally could not overprint.
On a paper printing terminal, the X's, the O's, and the *'s would all
print on top of each other on the same line. As noted, this sort of thing
was often used for password entry for terminals running in half-duplex
mode. However, ASCII terminals usually ran in full duplex - but that
depended, of course, on the computer system used. The IBM 2741, on the
other hand, was half-duplex (it wasn't ASCII) and, as noted, WMBI was a
common password mask for it.
John Savard
Martin Ibert
On 21 Dec 1997 11:48:56 -0500, gr...@sherrill.kiva.net (Gregory Travis)
wrote:
>^D is only the EOF marker (unless reset to another character) for the
>read(2) to return EOF. Only when the file descriptor passed to read(2)
>is a tty and only when that tty is in cooked mode will a ^D get
>translated to an EOF.
Not even that is entirely true. The story is somewhat more complex. If
you type ^D, everything typed on the line so far is transmitted. If
you type some characters, then ^D, the characters will be transmitted
to the shell. If you did not type anything on the current line, ^D
will immediately transmit just that - nothing. read() will return 0,
and that, finally, is interpreted as an end-of-file condition.
--
Please visit http://www.snafu.de/~martini/ for contact information!
-------------------------------------------------------------------
|Blind faith in your leaders, or in anything, will get you killed!|