Re: [5.1.4] Recommended way to work with Telnet server?

[Axel Kittenberger <axkibe@...>]

Telnet is an excellent example of something that first starts very
trivial in its basics and then quickly scopes upward getting
enourmously complex with all different enhancements and fixes of
problems/needs for it.

Trivial: you just consider it just a TCP-Socket to send and receive Ascii data.

Complex: you want to make it feel like a sane terminal, you have to do
terminal codes, special keys, localisation, ansi code, environment
variables, terminal capabilities information, screen info storage,
etc.  There is a reason why there are "pty" devices on Linux for
otherwise such a trivial thing than a in/out data stream. If you are
going to do a serious terminal emulation you should consider streaming
data through one of these.

How far you need to go depends on what you need it to do.

Generally "expect" is a wonderful to do this kind of remote shell
scripts. Only problem with it, it is TCL. There are various other
bindings to other languages, with various success/elegance. Do not
know how well the lua binding is exisiting/working. I did something
like that in python some time ago, but there it lost its beauty it had
in TCL (but otherwise ugly language) to be an arbitrary enhanceable
language, which made expect scripts look elegant.

On Tue, Feb 22, 2011 at 1:49 PM, Rob Kendrick <rjek@rjek.com> wrote:
> On Tue, Feb 22, 2011 at 12:37:18PM +0100, Gilles Ganault wrote:
>> Hello
>>
>> I need to write a script to interact with a Telnet-based server:
>>
>> http://ofps.oreilly.com/titles/9780596517342/ch20.html
>>
>> Alternatively, the server can also be reached through URLs, but the
>> client must support cookies.
>>
>> I'd like to know if LuaSocket is the best solution for this, or if I
>> should look at another add-on.
>
> If the server does not make use of out-of-band data or terminal control
> codes, then using LuaSocket would be trivial.
>
> You'll have lots of fun implementing the state machine to cope with
> Asterisk's hideous protocol, though.  (Not all actions have IMAP-style
> tags, and not all of them provide responses, etc.)  Been there, suffered
> that :)
>
> B.
>
>