Karlis wrote:

>     My problem is as follows: in application to get data from stdin I use
> gets. When running program with linux console as controlling terminal,
> backspace character works (because linux buffers input for me and give
> complete line to program). But when I run programm in telnet session and use
> basckspace (to edit data that was typed with mistake), I get "^[.." things -
> control codes displayed in ASCII.

Then your telnet program (or the terminal from which you're running
it) has its keys configured wrongly. BackSpace should generate either
ASCII 8 (^H, \010) or ASCII 127 (^?, \177). The Delete key typically
generates ESC[3~ (ESC = ASCII 27, ^[, \033).

>     I can turn this behaviour off by turning off terminal attribute ECHOCTL.
> But that does not solve the problem - I receive all those controlcodes into
> string I read from stdin (e.g. backspace as 0x08), and backspace moves
> cursor 1 position back, not deleting character. Is the only way to make
> backspace work to turn off echo, disable canonical mode and process each
> character, implementing echo by myself on stdout, and take proper action
> when non-printable characer is received?

If receiving a \010 doesn't erase the preceding character, then the
terminal is probably set to use \177 as the erase character; either
set the telnet package (or terminal) to send \177, or use

        stty erase ^V^H

to make \010 the erase character.

>     If I am missing something from these crazy terminal things, please
> enlighten me!
>     Maybe there is something to do with termcap? As far as I understand,
> this database contains "strings" which I have to type when I want to do some
> action (e.g. to move cursor up). Is that right?

That is correct, but it doesn't usually apply to BackSpace. If the
terminal driver is in canonical mode, it handles the erase character
itself, so the application never gets to see it.

-- 
Glynn Clements <[EMAIL PROTECTED]>

Reply via email to