Hey all,

I'm wanting to do a little side project for work in which I will need to use interprocess communication. I'd like to write it as either a perl script, bash script, or a C++ program. I'd prefer that it was one of the latter two. Can anyone give me some hints on where I should be looking for information about how to pipe information back and forth between processes? One of the main things I'll need to be able to do is to have my control process (the bash script, perl script, or C++ program) control a telnet session.

Any help would be greatly appreciated. Thanks in advance!

AFAIK, no standard telnet package has any ability to read/write IPC queues, shared memory, or semaphores; at least not for the purpose of communicating with other applications.

I will hazard a guess that you want to create a scheme where your software replaces the actions of a human operator typing into and viewing a telnet session. I have accomplished some very simple-minded arrangements like that, using GNU screen to contain a running telnet session (actually, I prefer Kermit), and a perl script that grabs from the screen session and stuffs characters into the session. It is a major hack, as you may have guessed.

There is the program expect, which may address your situation. Perhaps someone well acquianted with it can add some useful comment on it.

Given how simple telnet itself is, you may find it easier and probably much cleaner to write some TCP code into your overall application, to perform the network side of the job. This might be beyond bash scripting, but certainly not perl or C++.

--- rod.

That def sounds like a Perl job to me, although I guess it depends on which lang you know best.
I wouldn't try it in bash though.
For Perl you'll need to look at search.cpan.org to get the modules which will do all the heavy lifting for you.
Another good resource is http://www.perlmonks.com/

If you need to control a telnet session programmatically, consider using expect. Expect was originally bound to the TCL language, but I think there are bindings to perl and python.

Expect lets you spawn a process with a pseudo terminal, and then watch the output of that process, and according to that output, emulate terminal input by sending commands. You can even control multiple processes, decide at some point to connect them to the actual user's terminal etc.

Expect can be used to automate long processes where different commands are issued according to the output of previous ones. This is very useful in testing environments.

Another typical use for expect is to administrate multiple machines, e.g.taking a list of 100 machines, logging into each one in turn, issuing some commands (e.g. adding a new user account), logging out and moving to the next machine. Although there are already tools to perform this sort of mass-admin, using expect gives you more flexibility than many of them.

While you can automate logins, it's not generally considered a good idea for expect to send the passwords itself. It is tempting, but this sort of thing should really be eliminated (by using ssh and public key authentication). There are times however when it's still necessary.

Thanks for all the great responses, guys.

What I'm wanting to do is to exchange some SMTP commands with a mail server (which I do manually using telnet). Is there a way I could incorporate all the network interaction into a C++ program without having to bother with IPC and telnet?

I was in hopes that there would be some standard way to simply redirect the input and output of any process to/from another process thus allowing a bash script, perl script, or C++ program to control just about anything. I guess I had my hopes a bit high.

Expect will do exactly what you want.

You can do almost anything you want over a TCP network in C++, but it is probably easier in perl. There are many perl modules already written to do the low-level network stuff. You would just have to drop the right one(s) in, and wrap your application around it. A search on cpan.org, for SMTP, turned up tons of relevant hits.

After skimming through the expect man page, it really looks like that might be the way to go, too. This would seem to fit your desire to use the 'one program controls another program' scenario.

--- rod.