29 Dec
2007
29 Dec
'07
10:29 p.m.
What I've heard---there is no one character that
returns the carriage
to the start of the line (CR) and advances down one line (LF).
Sometimes there is; I have used hardware having a mode wherein there is
a single code on the serial line that performs that function.
Another recurring issue for ASCII: what is baskspace
supposed to do?
I'm used to systems that use $08 [1] to move the cursor left one
column and overwrite the character there with a space. But Linux
(maybe because Linus was secretly a DEChead?) decided that $7F would
move the cursor left one column and overwrite the character there
with a space, but X Windows (which I use on Linux) seems to want to
use $08 for that.
There's an ambiguity here: are you talking on input or on output?
On output, 0x08 usually moves one space left and does nothing else
(though I've heard of hardware that overwrites the character moved onto
with a space), and 0x7f usually does nothing.
On input, "it depends". On VMS (which I went through my larval phase
on), 0x7f was the "delete previously-typed character" code and 0x08
was...I don't clearly recall; I think it was just another nonprinting
input character, like 0x05 or 0x16. On Unix variants, it depends even
more. There's a tty driver setting which controls what character the
tty driver treats as an erase character; this can normally be set to
pretty much anything, including 0x08 or 0x7f. And a lot of software
does its own input line editing, in which case it's up to that
software; a lot of it treats either 0x08 or 0x7f as "delete previous
character". Whatever performs the delete-previous function is usually
echoed as multiple characters whose effect is to back up one space and
blank out what was there, which sounds a lot like what you describe.
The X Window System ["it's a window system named X, not a system named
X Windows"] does not, strictly, do what you describe. First, because
in X you don't type characters; you type keystrokes, and they get
turned into characters, if at all, by the choice of the client handling
them. Second, because input line editing - indeed, the notion of
collecting input into lines - is also a client-specific notion.
Terminal emulators like xterm usually leave this up to whatever is
listening on the pseudo-terminal in use, which means the applciation
running there and/or the pseudo-terminal driver in use by the
underlying OS. Other applications may or may not provide any line
editing; when they do, they usually have some way to configure what
keystrokes perform what functions; if they don't have such control,
it's by choice of the application author, not something imposed by X.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B