Linux Readile library through telnet

Hi, All. In my Linux program I need to have a simple command line input and use telnet as command console. I try to use Linux readline library. It works when I use standard input and output. When I open socket, associate file "dirstream" with it and make redirections: rl_instream = dirstream; rl_outstream = dirstream; the readline outputs prompt to remote telnet console, but I cannot input the command. And I see following warning: "rl_prep_terminal: cannot get terminal settings." Can anybody give an advise? Thanks in advance, Alex.

Reply to
Alexander Baranov
Loading thread data ...

Reply to
Aleksandr Baranov

I doubt that the readline library impliments the Telnet protocol.

formatting link

formatting link

--
Grant Edwards                   grante             Yow!  CALIFORNIA is where
                                  at               people from IOWA or NEW
 Click to see the full signature
Reply to
Grant Edwards

where

Well, being unexperienced, I've asked a wrong question. Really, I don't use telnet, I want to make a telnet-like terminal. I created TCP server, connected a stream with the socket and work with this stream as with input - output device. Now I would like to make Readline handle incoming characters from this stream. Sorry for inaccuracy.

Reply to
Aleksandr Baranov

No worries.

The phrase "I ... use telnet as command console" wasn't accurate?

So you're not using telnet at all, and you've written your own TCP-connected console client and server programs?

Sounds like you're trying to re-invent telnet. :)

When I've wanted to do what you're describing, I've always just implimented the bare minimum of the telnet protocol and then used telnet clients. Since that's not what you're doing (and I know little about the readline library), I'll bow out of the discussion...

--
Grant Edwards                   grante             Yow!  Yow! I'm out of
                                  at               work...I could go into
 Click to see the full signature
Reply to
Grant Edwards

Aleksandr Baranov wrote: [...]

I think you may be wanting to send lines to the server, rather than characters. If that's the case, I'll assume some things.

Readline will help you edit lines locally in your terminal without the server ever knowing that you are backspacing, using command completion, or whatever. When the line is ready, hit enter, and the composed line is sent at once? If this is the case, readline and TCP don't care about each other.

If you want the incoming characters from the connection to be processed through readline, then things get a little deeper. Readline wants to know a little about who it's sending characters to - such as whether it can do smart or dumb backspacing. This knowledge comes from the terminal type, such as ANSI, VT100, xterm, etc.

It this really what you want to do? You'll have to send characters one at a time. Maybe a little more explanation would help.

Server|read|TCP-------------------TCP|write|Term Client|keyboard|human Server|write|TCP------------------TCP|read|readline|Term Client|display|human

If this is what you want to do, it's not making a lot of sense to me, sorry.

--
------------------------------------------------------------
Creepy, Soulless Gigolo for President ? NOT !
 Click to see the full signature
Reply to
Bryan Hackney

You have two options.

- make a new login account; have the shell call your program (ie, call your program from .profile / .login / .whatever)

- make a new login account; change the shell for thi account to be your program.

If all this sounds weird to you, then you need to read the man pages for login(1), bash(1), and probably getty(8).

Kelly

Reply to
Kelly Hall

use

input -

characters.

server ever

When the line

case, readline

through readline,

it's sending

knowledge comes

a time. Maybe

Client|display|human

sorry.

Well. I would better explain from the beginning. I will have a single board computer with Linux, which will receive data from serial port, process it and transfer through Ethernet. It will not have keyboard and monitor. Somehow from time to time will I have to issue commands to it. I decided to do it using Ethernet connection. I'm going to create a simple TCP server and bind it with a stream. I decided to use port 123. Then I will connect notebook to the network and run "telnet on it. Now my notebook's telnet is ready to send characters and my SBC computer starts receiving these characters from the stream associated with TCP server. My program has to handle incoming characters from remote telnet console characters, handle left and right arrows, DELs, BS etc. On getting CR the obtained string has to be processed by parser. While I was in the middle of this work I was told that the readline library does all this routine work and all, that I have to do is to install it and make it work with stream rather than with standard input and output. I installed the library, it works fine with standard console, but I cannot make it receive characters from stream. Instead it outputs warning: "rl_prep_terminal: cannot get terminal settings."

Thats the whole story.

Reply to
Aleksandr Baranov

I'd recommend using the Telnet protocol, since then you won't have to write a client program.

But in another post, you said you _weren't_ using Telnet. Which is it?

Readline probably expects to be connected to a tty device. You're connecting it to a TCP socket. There are various termios ioctl() calls that tty devices support that sockets don't.

The standard way to handle this problem is for the telnet server (which you are writing) to use a pty pair to pass data to/from the "shell" (in your case the readline library). That way the "shell" (readline) program sees a tty device like it expects.

If you _are_ using Telnet, then you could just put it in line-buffered mode with local echo enabled, and then the editing is done by client program, rather than the server program..

Or you could hack the readline library so it doesn't expect a tty device and just deals with a byte stream.

Do you have enough memory to install busybox on your SBC? IIRC, it impliments a telnet server, shell, and command-line editor...

--
Grant Edwards                   grante             Yow!  UH-OH!! We're out
                                  at               of AUTOMOBILE PARTS and
 Click to see the full signature
Reply to
Grant Edwards

We don't know if he _has_ a shell on his SBC, if he's running any sort of init or getty, or ...

--
Grant Edwards                   grante             Yow!  My DIGITAL WATCH
                                  at               has an automatic SNOOZE
 Click to see the full signature
Reply to
Grant Edwards

He started the question off with "In my Linux program..." so I sort of assumed he was, well, running Linux. My apologies if my assumption was unwarranted.

Kelly

Reply to
Kelly Hall
[...]

Ah, much better. I think I see where there is some confusion, or maybe the wrong (or harder) approach.

Using readline is fairly easy, although it seems a little crufty. And it is GPL, not LGPL, so when you link with it you are under the GPL (if you care).

Readline and curses go together somewhat (I can't remember if curses is required). And curses is way crufty. I recommend the approach of composing and editing the lines in the terminal window, and sending only the completed line to the server.

If you want to capture and send individual keys to the server, then readline becomes less useful or even precluded. Readline is line oriented.

If you want to process and send individual keys, then you probably have much work to do, and I would not recommend doing that without a very good reason.

I think you want it to work with the standard in and terminal disciplines, the way you describe.

human|keyboard|readline+curses|term prog|write|TCP-----------TCP|read|server ||| display

human|display|curses|term prog|read|TCP----------------------TCP|write|server

--
------------------------------------------------------------
Creepy, Soulless Gigolo for President ? NOT !
 Click to see the full signature
Reply to
Bryan Hackney

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.